epic9x's comments

This blog post covers in a lot more detail why the design behind mynd is actually interesting: https://blog.teufelaudio.com/visionary-mynds-insights-on-teu...

Nuts and bolts; - Users can replace batteries with just a few screws, and everything is modular. - Components like batteries, PCBs, drivers are from mainstream suppliers and easily replaceable to minimize waste. - Teufel has released full schematics, PCB layouts, firmware, and 3D-prints for the housing.

This thing is crazy fast.

Start by using home-manager in your current environment. Once you can modularize your own config, start building other systems with it. It's a very deep rabbit hole, and starting off as a replacement for managing your own dotfile scripts and the like is a great way to try it out without having to replace whole systems.

Portability and other constraints I've discovered with the shell have always been a sign I need to reach for different tool. Bash is so often a "glue" language where accessibility and readability are it's primary feature right after the immediate utility of whatever it's automating. Writing POSIX compatible scripts is probably safer and can be validated with projects like shellcheck.

That said - this is a neat project and I've seen plenty of "enterprise" use-cases where this kind of thing could be useful.

I have no frame of reference for how PTSD must impact your life but it must be so hard - thank you for your service.

I do have empathy and a frame of reference as someone who also struggles with quality and quantity of sleep - sleeping only four hours a night makes you a train wreck of a person. Even if you could and do this now, it is not sustainable and can create feelings of extreme burnout. You likely you have become numb to how vast an impact this is having on you. (I say this as someone who ignored this for years and realized I was losing weeks at a time to living in a fog of exhaustion). I urge you to work on this and then make a bigger life change.

You might want to include rental income as an option here, lots of folks may have a place that includes an attached unit.

If you can run your system on a single machine, you don't need an SRE.

If you have hundreds or thousands of machines, that's an indicator that you /may/ have the complexity that requires the disciplines that can come from dedicated SRE. The tough thing is conflating filling operations problems with a role named SRE, versus actually using the best practices that will help you scale and improve reliability.

Excellence in (open source or otherwise) security practices are the exception, not the norm.

I've worked in multiple large companies and even getting package signing turned on requires a lead pipe. Docker and tools can enable an org to move those types of responsibilities "over/down" to the developer as well, so that now there is no neck-beard encrusted gate at all.

Cites $200 million to build, which seemed high until you see they're actually giant neon advertising signs too: http://www.link.nyc/assets/downloads/LinkNYC-Media-Kit.pdf

The city gets guaranteed profit of $20 million annual with projected rev share of much higher than that. Solid deal.

This is indeed a huge bummer, now that I've upgraded to yosemite I've got 1-2 full seconds of lag streaming audio to my blue tooth receiver.

It's actually not uncommon in some larger cities to get utilities completely paid. I'm just outside of DC and only pay rent and cable.

congrats! I remember seeing your first post and sticking with it. start day 181 by rewarding yourself - you earned it!

RAID 0 is generally frowned on in pretty much all circumstances. Is there a specific reason you're using it? (Legitimately curious.)

Agreed, the use of emoji or the occasional ";D" is a measure of how informal the communication is, and isn't something that'll help improve the professional tone interacting with a client. I personally don't think it has much place in business communication at all, but that's just my personal preference.

If you can't communicate successfully without emoji, then you have a large communication problem that is likely not being solved by their addition.

edit: for clarity.

You're not providing any data to say having KeepAlive on would've 'crushed' the server, actually quite the opposite. For example - with KeepAlive on, your site response time was 5.31s. With KeepAlive off, it was 6.87s. So with your own test it was slower to load.

With keepalive off, your server would spawn new connections for every request rather than re-using them. With mpm-worker and threads, that's not so bad. However I've seen a lot of people run pre-fork which uses processes instead of threads which can be a Bad Time(tm) with heavy spikes in traffic.

Anyway - found this here (not my site) - explains it fairly well: http://abdussamad.com/archives/169-Apache-optimization:-Keep...

Blindly turning off KeepAlive isn't a recipe for awesomeness.

KeepAlive is a trade for memory/cpu time; on if you want to speed up in exchange for memory, off if you want to conserve memory and pay the cost of initializing new conections.

If you're doing anything like loading a web page with more than a few images, KeepAlive will likely improve connection time as http requests things serially, and you'll have a speed up by re-using the same connection.

Protip: run apache's mpm-worker with keepalive on and save memory and speed up your site.

Regardless of whether or not HTML5 is going to "lag", I think this article white-washes the evolution of the web as an open platform vis-a-vis the desktop/OS. Open platforms and protocols are the result of hard work and people taking risks and building value, not a result of stability in the platform.

The Web and technologies have operated in a disruptive manner with respect to an established platform, and the mobile revolution was about the platform moving to serve modern, networked users. The is counter to silo'd interests attempt to constrain and integrate the web into proprietary formats and platforms (See: everything from active-X/flash to the current mobile platform wars).