Because in addition to all the filthy pirated booty I stole, I would also show them this:

    * My 350+ physical CD collection
    * My 200+ physical DVD/Blu-Ray
    * My entire merch collection for Nine Inch Nails (>$1000)
    * My entire merch collection for Rings of Saturn (>$1000)
    * My merch collection from many, many, many other bands
    * Pages of receipts from Bandcamp and other e-media distributors
    * Pages of receipts from direct payments to artists themselves
    * The mass of ticket stubs I've acquired from live shows
    * The mass of movie ticket stubs I've acquired from theaters

Fuck them. It's over.

Have fun paying to sing "Happy Birthday".

Sorry... just musing on this topic because this is giving me a laugh.

There are glycol stations but as I recall those are really only used in gathering systems with a compressor. The large plants will have tons of equipment online to condition the gas before pushing it upstream. The biggest issue we ever had was just baby-sitting compressors in the middle of the night because some of them just really don't like to operate in cold conditions.

I used to test the gas in a lab and there wouldn't be enough water vapor left in the line to cause any issues under freezing. You have far more issues with carbon sludge build-up since anything above butane just really wants to be a liquid. That area typically produces wells with something like 4% N2, 70-80% C1, 2% CO2, and the rest is basically C2+ with maybe some H2S in a few places. It's very easy gas to pipe around for the most part.

No. I had used CVS, SVN, SVK, Bazaar, and Mercurial for years before I switched to Git. I can generally explain the internals of all of these tools (a DAG) to someone in simple terms in minutes. Overlaying that onto the commands becomes easy.

What Git does is take that concept and wrap it in the worst possible workflow UI. The people that immediately grafted onto the Git community cheered this on for some reason very early and then recanted by saying that you are really supposed to build "porcelain" for Git since it was meant to be a rough tool.

To this day all I see are articles about people's confusions and conniptions over simple things that Git does incorrectly because it's UI is horrible. Most can't even get to the point where they understand the DAG. Even though I know what is supposed to happen it's hard for me to fumble around with simple commands because the naming is inconsistent and I have to research to find solutions. This was rarely an issue with Mercurial and when I talk to people that have used both they seem to share that sentiment.

Git is the PHP of version control. Widely used and very popular but has a lot of architectural problems that make it a total mess.

> I never questioned the competence of past engineers

False just based on your opening volley of toxic spew. Backwards compatibility is an engineering decision and it was made by very competent people to interoperate with a large number of systems. The future has never been fucked over.

You seem to not understand how ASCII is encoded. It is primarily based on bit-groups where the numeric ranges for character groupings can be easily determined using very simple (and fast) bit-wise operations. All of the basic C functions to test single-byte characters such as `isalpha()`, `isdigit()`, `islower()`, `isupper()`, etc. use this fact. You can then optimize these into grouped instructions and pipeline them. Pull up `man ascii` and pay attention to the hex encodings at the start of all the major symbol groups. This is still useful today!

No, the biggest fuckage of the internet age has been Unicode which absolutely destroys this mapping. We no longer have any semblance of a 1:1 translation between any set of input bytes and any other set of character attributes. And this is just required to get simple language idioms correct. The best you can do is use bit-groupings to determine encoding errors (ala UTF-8) or stick with a larger translation table that includes surrogates (UTF-16, UTF-32, etc). They will all suffer the same "performance" problem called the "real world".

If YouTube would be willing to charge me something in the neighborhood of $5-$10 per month for that I'd happily pay. I have never had a Netflix subscription. I stopped consuming pop content and movies in 2010.

I am serious about this. If you have any way of making recommendations to anyone anywhere within Alphabet that will listen, please offer it up. I would point you to a site like HistoryHit which is far more in-line with what I want. It is $60/year.

Also, I already pay $5/month to the Kevin Richardson foundation and the ad-blocking mechanism on YouTube prevents me from watching those videos (which I paid for).

If you don't want ad-blockers, shut it down.

Because they offered it for free.

YouTube can close the doors any time. If they want my money, they can make a service offering that meets my needs. They could charge content providers for bandwidth and storage and meter it with assisted ad-support networks. They could charge a price I'm willing to pay.

But they don't and I will not accept any argument that consuming resources they put into the public sphere for free use means I am under any moral obligation to either give them money or facilitate them making money off of my traffic.

The only time ads worked was when Google made them an unobtrusive part of search. They dominate literally every piece of software I use now. I'm sorry but I say burn it all to the ground. I will either pay for or build its replacement.

You don't want ad-blockers? Shut it down. I was doing the internet before there was a need for them.

That's why we aren't getting nuclear right now. Once the regulatory hurdles come down and all of these questions get answers it'll be clear how to make a return on nuclear investment and that will attract investors.

Also, solar (and all other "renewables") are only quick to build assuming you have raw materials. We are probably going to be hitting a raw materials crunch soon because virtually all new technology is pulling from the same resource pool (copper, molybdenum, nickel) and cheap extraction is effectively gone.

Also, from an investment point of view, I'm not sure why you'd prefer a more volatile commodity. All commodity markets were set up to reduce volatility and base-load power is a huge reduction of electric grid volatility. You are telling me you'd prefer a world where you have intermittent failures because you could set it up more quickly than have reliable, constant, always-on base power for cooling/heating, food, hospitals, etc. Most people think that's a bad trade-off, hence the desire to have nuclear become the base-load provider fuel of choice.

I've spilled concentrated round-up all over my arms and legs many times because I used it regularly as weed control all over my property in Texas. I've also been regularly exposed to all sorts of noxious chemicals like acetone, gasoline, diesel, various alcohols, and many different organic compounds in general. On bare skin (solvents get your hands clean fast!). Part of my life is a mixture of agriculture, oil/gas, and just general West Texas grime.

I eat virtually 100% meat now which is also supposed to give me cancer. The teflon-coated pan I use to cook eggs doesn't have much teflon anymore because I've scraped most of it off through cooking (I never wash it). When I was a child, J&J baby power was an absolute staple in all households I ever visited and I've inhaled clouds of it. I have been sun-burned countless times in my life and still regularly seek long intervals of intense sun with no sun-screen. My family were early adopters of cellular phones so I've been exposed to brain-cancer causing RF/EM radiation for over 30 years now.

No cancer. No diseases. No allergies. No excess pains. No respiratory issues. No mental fog. No general health issue to report in any way. I'm the healthiest and fittest in my life at 47. I never go to the doctor any more because the last few times I went all of my lab work came back perfect.

Maybe one day I will get some fatal disease or just get run over by a truck. For now I'm going to just keep betting on the odds, though. Most of the health fears I see today seem to have an extremely low chance of occurrence (if at all) and many times is confined to very niche cohorts. The science behind most of it is pure garbage and popular opinion is generally driven by court case outcomes rather than verifiable facts.

I'm sorry for your loss, but there doesn't need to be "justice" for every case of bad fortune. There has never been a causal link to cancer with glyphosate and it has been well studied and used for many, many, many years by many, many, many people.

    * Physical space - The servers themselves require a certain amount of room and depending on the workloads assigned will need different dimensions.  These are specified in rack "units" (U) as the height dimension.  The width is fixed and depths can vary but are within a standard limit.  A rack might have something like 44U of total vertical space and each server can take anywhere from 1-4U generally.  Some equipment may even go up to 6U or 8U (or more).

    * Power - All rack equipment will require power so there are generally looms or wiring schemes to run all cabling and outlets for all powered devices in the rack.  For the most part this can be run on or in the post rails and remains hidden other than the outlet receptacles and mounted power strips.  This might also include added battery and power conditioning systems which will eat into your total vertical U budget.  Total rack power consumption is a vital figure.

    * Cooling - Most rack equipment will require some minimum amount of airflow or temperature range to operate properly.  Servers have fans but there will also be a need for airflow within the rack itself and you might have to solve unexpected issues such as temperature gradients from the floor to the ceiling of the rack.  Net heat output from workloads is a vital figure.

    * Networking - Since most rack equipment will be networked there are standard ways of cabling and patching in networks built into many racks.  This will include things such as bays for switches, some of which may eat into the vertical U budget.  These devices typically aggregate all rack traffic into a single higher-throughput network backplane that interconnects multiple racks into the broader network topology.

    * Storage - Depending on the workloads involved storage may be a major consideration and can require significant space (vertical Us), power, and cooling.  You will also need to take into account the bus interconnects between storage devices and servers.  This may also be delegated out into a SAN topology similar to a network where you have dedicated switches to connect to external storage networks.

This is what Oxide has to offer. They have built essentially an entire rack that solves the physical space, power, cooling, networking, and storage issues by simply giving you a turn-key box you plant in your data center and hook power and interconnects to. In addition it is a fully integrated solution so they can capture a lot of efficiencies that would be hard or impossible in traditional design.

As someone with a lot of data center experience I am very excited to see this. It is built by people with the correct attitude toward compute, imo.

I have professional experience with all of the technologies involved and the biggest hurdles are getting time to work on it and dealing with the absolute horror that is HTML/CSS/Mobile. Once I can get enough built I can farm that out to someone else, though. In the meantime I'm still hoping to win the lottery while not wasting any money on tickets :)

If for some reason you really do need to transmit this data in-band (ultra rare use case) you should at least be using something like HMAC to verify that all carriers have transported the data unmodified. It is your responsibility to ensure the integrity of the data end-to-end.

I use uBlock Origin on YouTube specifically to work around many UI issues related to their recommendations and player. I will not turn it off. One example is that they will not honor my closed-caption settings on all videos so I have a filter rule to remove the call to the captions URL to eliminate them. That's one of countless issues.

They are now denying me access to a service for which I do actually pay for. I consider that to be illegal.

My proposal is simple:

    * Give me an option to pay for what I use.  I do not want music, 99.9% of live streams, news, or tons of the other content they try to force on me for money-making purposes.
    * Make the price reasonable.  The videos I watch are primarily educational lectures.  This really shouldn't cost much more than the price of disk storage and network egress (both of which are cheap at scale).
    * Give me a recommendations and preference system that actually work.  I spend more time curating my list of videos than watching anything meaningful to my interests.  At one point I was watching 2 luthiery channels and "guitar necks" came up as a category.  What the ever living fuck?  Related yes, but not quite the topic I really want to focus on.  I would remind people that this is a multi-billion dollar company with PhDs that has changed the face of AI and hyper-scale computing as we know it.
    * In general, operate like a long-running business... offer good value to your paying customers.  Now that the customers are not advertisers, Google will need to rethink their sales strategies.  They have not yet convinced me.

    * Most simple things like a "Person" were multiple tables because you had to include audits and historical changes for each field
    * A "Person" wasn't even all that useful because it included guests or other fairly transient entities like vendor contacts so you had an explosion of more tables as you classified roles into "Student", "Faculty", "Employee", etc... (many with histories as above).
    * Addresses and other non-core demographic information were usually sharded into all sorts of categories like "primary", "parent's", "last known good", "good for mailing", etc... (more histories, etc...)
    * All coded information like label types such as "STUDENT", or "MAILING" were always handled as separate validation tables with strict FK constraints and usually included extra meta information like descriptions and usage notes within parts of the system.
    * Each functional sub-system (HR, Payroll, AR, AP, etc.) had its own dedicated schema.
    * All external jobs, processes, and external integrations were configured separately.
    * All enterprise integrations usually had a whole a dedicated schema for configuration.
    * Most parts of the interactive web UI were database driven (Oracle's Apache mod PL/SQL) with many templates and other components stored in large collections of tables.

Also, OpenBSD really doesn't have a huge install base. It's a fairly niche project and the people that work on it really don't care about Linux at all. You'd have to find someone with the skills to be able to translate between the two, the time to do it, and the desire to do it. I have the skills and most of the desire but not the time otherwise I'd be working on projects like this. I've been getting pretty sick of the Linux eco-sphere for a while now so it'd be nice to have some saner production tools. Unfortunately I have to have a day job and no one at work even knows about OpenBSD.

The first step was to find the location and park the drilling rig so it wouldn't sink once the well was dug. Then you'd raise the drill arm, attach a section of pipe and the drill head. You'd lower it down into a round flange that had an opening to one side where all of the cuttings blew out. My job was to shovel the cuttings into a trench to direct water flow once you hit the water line. It was critical to keep water from getting under the tires of the rig.

Each section of pipe is 20 feet long and as you drill in you detach the rig head, raise it, get another section of pipe from a rotating carousel and then start grinding again. Once done you pull all the pipe by basically doing the reverse and then perform a similar operation to push casing down into the hole. When the rig pulls away you have a round hole in the ground ready to have another truck come in to insert an electric pump with all the wiring. Then you box everything up at the top and say job done.

Oil field drilling is pretty similar as well but the rigs are vastly larger and move way more earth much faster. My dad worked on a rough necking crew and I've been exposed to the oil and gas industry most of my life so this is an interesting tangent.

A lot of databases are just data structures written to disk in an efficient manner. There's nothing really stopping anyone from doing the same and implementing the query language as a direct API to these on-disk structures. In my mind this all just falls under the general category of random access files. This can be extremely performant if you are very knowledgeable of your use case and storage characteristics.

SQL on the other hand is a query layer on top of these data structure engines which gives you a more general purpose language to work with. It doesn't map directly to the underlying data structures so you can model data differently at a more abstract level. Ultimately it will be compiled down into some sort of routine that attempts to perform data access to those underlying data structures in as optimized a manner as it can figure out.

It's all about trade-offs. There are also plenty of storage engines that already give you an on-disk data structure in a box (e.g. RocksDB).