pravus

Why would an IP rights-holder believe you?

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".

This is what I'm asking... It's like going to the wholesaler and wondering why they don't have a nice pretty brick-and-mortar to buy from. GS doing consumer credit just seems like a large impedance mismatch in various levels.

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

Look at the dip in Permian versus Haynesville, Eagle Ford, Barnett and Fayetteville. Permian is West Texas where I said I was and it didn't even dip below the previous low. East Texas is a whole other country...

I'm not sure how much it would really be needed. Part of my family owned and operated a gas measurement business in West Texas and I don't recall ever having to do anything special for winter conditions on pipelines. Most of the water and oil comes out with the plunger lift in the well head and is stored on-site next to the well. Trucks come to haul it off and one of our jobs was to coordinate all of that plus maintenance.

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.

There’s a meme that Git is hard to use but I think it’s conflating the challenges of getting used to version control at all

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'm guessing due to some backwards compatibility idiocy that seemed like it made sense at some point ... ... making a compelling reason to fuck over the future in favor of optimisation now

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".

Maybe it's just me and my bad attitude toward products today but this could explain why everything seems to be turning into low-quality garbage. I'm not a millionaire business man so I must be doing it wrong, but spending over 1/3rd of your revenue stream on customer acquisition rather than anything product-related seems like a bargain I don't want as a consumer.

I watch primarily wildlife documentaries, educational lectures, and podcasts related to academic topics like paleontology, archaeology, ancient history, and other subjects. I don't want music, live shows, television, sports, or most content that would incur a premium markup.

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).

My Service Provider License Agreement states that I am able to circumvent any ad technology when using my own devices. It is free. The "with ads" part is someone else's opinion.

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

Why do you pretend that you are entitled to free video storage and bandwidth from YouTube?

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.

I get that we -need- electricity at night. But frankly, there is zero incentive for me to put my billion there. Its high risk with no reward.

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'm not telling you what to do, but I really wish this kind of thinking would stop.

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.

In a data center you have racks of computers performing all of the workloads. At this point these racks are fairly standardized in terms of sizing and ancillary features. These are built-out to solve the following:

    * 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've thought along the same lines. I currently have some personal projects going in this direction. My vision is to create a set of tools that would allow you to set up a micro infrastructure to self-host all of these services on any cloud/hosting provider with a reasonable API.

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 :)

There's no reason to have a URL (or any data) encoded in the state parameter. The purpose of the parameter is to provide an opaque lookup key which you can utilize to provide correct, validated responses. This is usually done in some sort of database or Redis-like cache. My workflows have always used a random UUID for the state key and I just encode the necessary (validated) data items needed for the next step as a JSON blob. It's essentially a very short-lived web session.

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 currently pay $5/month to the Kevin Richardson channel as a member and have been a member since inception for over 4 years now. When I went to the members section of YouTube to view my members-only videos I received the blocking message and was denied access to the video player. This is in addition to other wildlife charities for which I send monthly donations directly.

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.

I worked at an educational institution where we ran an academic-focused Enterprise Resource Planning (ERP) system that was fairly large. Not quite 40k tables, but it had over 4k. To give you an idea of how this was organized:

    * 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.

It's really just the effort and time to understand the data structures and API considerations between the two systems. Saying something is a UNIX doesn't absolve you of the duty of knowing how the specific UNIX was implemented. Also, Linux has no UNIX heritage so relying on UNIX knowledge isn't as helpful as you might think and most of the commonalities are through things like POSIX standards which don't necessarily drive kernel internals directly. If the application relies on a specific kernel features, you might have a very complicated or impossible task ahead.

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.

This is interesting. Part of my life was working with a water well driller running a rig for my grand-father's business a long time ago. The technique is virtually identical but with a hydraulic lift for running the drill and uses compressed air to clear the bore.

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.

BTW the question I asked was about querying data without ever using a SQL language, like tapping directly into the data.

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).

I think it could be argued that the basic form of this was around as X.509 certificates far before blockchains. I'm not sure what the history would be before that, though.

Also, in my mind at least, the idea for doing secure attestable history comes from git. Once you have a crypto-DAG it's a fairly easy transition into other data structures although ordering becomes an issue with trees. I'm almost sure something else must have existed because it's not a far leap to a crypto-DAG when you are doing things like HMAC.

would it sound different?

I don't believe it would. While there can be pretty bad PRNGs, they are typically implemented to produce a particular statistical distribution which would be identical to a real random source for the purposes of white noise. This is due to the fact that audio is a superposition of frequencies which takes time and multiple samples to cohere.

PRNGs can be bad for things like crypto because each individual generated value has significant implications for the entire set of operations.

I recently set up my own self-hosted email solution again and made sure to do all of these things:

    * Proper A and MX record set up in DNS per SMTP standards
    * Proper SPF record in DNS
    * Proper DMARC record in DNS
    * Proper DKIM record in DNS
    * SMTP server (postfix) is not configured as an open relay
    * SMTP server is configured with a DKIM milter to sign outgoing messages

As far as I know this is about the best you can do. Everything else is pretty much getting your mail server IP addresses removed from various blacklists which can be easy to impossible depending on the service. The other option would be to forward to another service that allows relaying and has IP addresses with better spam scores but I personally prefer to avoid that.

Can perfectionism be "cured"?

I don't really consider it a "cure" but the way I manage my perfectionism (and holistic completionism) is to simply re-frame my goals to not meet perfect but to get as close to perfection as possible. As long as my actions get me closer to my goal, I am satisfied. It's a very brute-force and reduced version, but another way to say it is that if you want to go North, just never walk South and iterate in steps.

Also, I've basically eliminated failure from my personal language. Any task that doesn't achieve the desired result is simply a delay and I re-adjust immediately to find a new tactic that will put me back on track. If the time-effort to proceed isn't worth it, I dump the effort and change strategies. I long ago got rid of the idea that anything I create is special or worth saving. Outcomes are what matter. It's a very pragmatic approach and eliminates the perfection tendencies because it gets things done.

When I was doing disaster recovery we measured three things: 1) the likelihood of a particular scenario, 2) the magnitude of the impact if the scenario unfolded, and 3) the level of effort expected to recover. It was the combination of these three things that prioritized decision making.

We were working towards a business continuity plan which can include incidents like your main office and operations being destroyed and having to quickly relocate all services to 3rd-parties using off-site backups with minimal staff. While that was a worst-case, a primary focus was just getting a notification site up and running in the event of a network outage because that was vastly more frequent and had high visibility.

It was a very interesting project and I learned quite a bit about how to think comprehensively about the solutions we provided.

Would we lose formatting, etc?

Basically you'd lose the entire source representation of your code so you are essentially shipping binaries at that point. You could annotate the AST with hints to recover the original source, but once you have an AST you also have the option of transpiling to other languages/representations.

This is essentially what things like the JVM, .Net, wasm, and any sort of embedded virtual machine are. The AST is kind of just the byte-code that gets executed since the machine abstraction isn't really tied to physical architecture.

I was hoping to see something like this. Thank-you!

What is the market for "wide" applications though?

Just my experience, but essentially these target industries, not necessarily consumers or singular entities. Hence the term "enterprise". As someone who worked on a fairly reasonable ERP for academic purposes, even just calculating a GPA is extremely complicated in the backend:

    * There are multiple schemes for calculating GPAs
    * Each scheme needs to support multiple grading types (A-F, pass/fail, etc)
    * Each scheme needs to support multiple rounding rules
    * Displays of GPAs will need to be scaled properly based on the output context
    * GPA values will need to be normalized for use in calculations in other parts of the system
    * State legislatures mandate state-specific usages of GPAs which must be honored for legal compliance
    * All GPA calculations must have historical context in case the rules changes so that old transcripts can be revived correctly
    * Institutions themselves will have custom rules (maybe across schools or departments) for calculations which must be incorporated into everything else
    * This pretty much has to work every time

I would compare this to most modern "tall" applications which would more-than-likely offer you maybe up to 3 different GPA options with some basic data syncing or something. They might offer multiple rounding types if they thought that far. These apps are generally extremely niche and typically work for very basic workloads. They can capture a lot of easy value for entry-level stuff but immediately fail at everything else.

I will admit that polymorphic types can still be pretty awful in an RDBMS. And yes, juggling sets can take some creativity with SQL.

Not really, imo. The biggest advantage of Mongo was being able to store a single hierarchical document and search it. Now that you can do that in the RDBMS there's no advantage at all. You also throw away all capability of doing relations in the database with Mongo which is optional in an RDBMS and sometimes very beneficial.

Mongo could win if it were more performant or had a better query syntax... but it isn't and it doesn't. It might have some slight advantage in the speed you can set up a replicated cluster but you'll pay long-term in overall performance from my experience. If all you are doing is storing documents, just use an S3 bucket, etc...