nrdvana

You could do the same thing with User Mode Linux or a virtual machine. WSL is just the easiest/fastest way to run native Linux binaries on a Windows system. If you have a X11 server installed properly on windows and can run Linux apps over ssh (which I've done with cygwin, but there are other paid options as well), then you can run them over ssh to a virtual linux on your own host, or look for ways to skip the ssh tunnel if they can route packets to eachother.

I'm a little surprised the examples don't require fiddling with X permissions, which I always had to do when not using ssh.

Well, that's sort of splitting hairs... It is a unix socket, which at the API level is the same as a network connection, but the kernel skips the hassle of attaching protocol headers and routing the packets.

The example above is writing and reading every X11 message over a socket, and not reaching into /dev on the host, else it would need additional parameters added to the docker command.

I'm not current on Wayland, but as of a few years ago all attempts to run it non-locally required the X11 back-compat layer. I have no idea what /dev nodes would be required to be shared for wayland to run in a chroot.

My "year of the Linux desktop" was 2018 when for the first time ever I was able to play a AAA video game (Deus Ex Mankind Divided) installed from Steam with nothing but normal GUI mouse clicks.

Sadly there haven't been many AAA games with Linux compatibility (that I wanted to play) since then. Valve is still pushing it though.

Lenovo ThinkPads actually have manufacturer support for Linux for quite a long time. (to the degree that there is actually a BIOS menu option for Linux sleep states specifically labeled as such) I've used ThinkPads for the last 10 years and had perfect support running Linux Mint.

Don't get me wrong, it will be nice to have another manufacturer to choose from with excellent Linux support, but as it sounds, they aren't there yet with this new distro. So... I'll keep using ThinkPads for now.

Also I despise glossy screens. So I'll probably never want a macbook anyway.

It's a big ball of wax with more details than I'll ever memorize, but I know for a fact that for the last 20 years or more X11 GLX has had "indirect contexts" where the application feeds the OpenGL requests over the display socket and the server renders them (possibly) hardware-accelerated. "direct rendering" is where the X11 client negotiates with the X server to make a direct connection from the application to /dev/whatever to talk directly to the kernel driver of the graphics card to do rendering that bypasses the X server.

The whole thing with Wayland is just a new generation of coders saying "hey all this pile of new apis on top of old apis on top of older apis spanning back 40 years designed for hardware that no longer exists is insane. We need to start over." They aren't wrong, but they also haven't reached feature parity with the old stuff yet, because doing hardware accelerated 3D graphics over a pipe to a remote host was a pretty amazing feat of technology.

Edit: to be a little more specific, Silicon Graphics company's whole business was accelerated graphics, and they were in business since 1982, and invented most of X11, or at least its extensions.

Wikipedia has a very thorough write-up https://en.wikipedia.org/wiki/Daylight_saving_time with 171 sources. What degree of certainty are you looking for? It mentions many examples of business (with emphasis on golf and golfers) who pushed to restore DST for the modern era even after the original energy-saving reasons had become obsolete.

Indeed its hard to generalize across all people. But I doubt many of those you list react favorably to the early times. Either way, they are likely not the ones wishing for permanent DST, because for some of them (like the ones waking up at clock 4:30am) it means they will go to sleep when the sun is still up (at solar 7pm) instead of after sunset.

You got that backward. Everywhere in the red gets worse during DST. In Ohio, the middle of the day occurs at 1pm on EST, and the middle of the day occurs at 2pm on DST.

I'm against DST because I think if people are going to wake up at solar 6am and go to work at solar 7am they ought to call it 6am and 7am instead of calling it 7am and 8am.

"Work is defined to start at 8am so lets have everyone call solar 7am '8am' so we can get everyone to go to work an hour earlier."

Now "high noon" will occur at 1pm and the middle of the night will be 1am. In Ohio (or west edge of any time zone) the middle of the day will be 2pm and middle of the night 2am. Sunburn zone in ohio? 12pm-4pm.

Sorry, the "farming" myth is one of my ocd triggers. DST is for golf courses and has never had anything to do with farming. Businesses want more daylight hours after office people get out of work to get those people to spend more money. This is the original trigger that caused the golf lobby to push congress to enact daylight savings.

The problem is the "consistent yardstick" actually. People are accustomed to start work at "8am", and react badly to being told to start work at "7am". So we change the clock so that their yardstick "8am" occurs at solar 7am and people get out of work earlier. And people now are like "lets keep summer time" which is the exact equivalent of "lets always go to work at solar 7am".

The law they passed is exactly equivalent to passing a law that puts us on winter time and starts a new requirement that schools and businesses open at 7am. We're just giving a new name to 8am.

It will all become more ridiculous 20 years from now when popular demand has lead to offices and schools opening at 9am in the winter and people start calling for a new daylight savings time to get more hours of light in the evening.

So a disclaimer, I have never read the C standard in full and I don't consider myself an expert, but this one about bit fields is one of many anecdotes I've accumulated over the years about portability. The rule is never use a bit field in a serialized file format because different compilers could interpret them differently. As long as a bit field never leaves the memory of the host that wrote it, they're fine. But in this case, you are expecting the bit field to overlay in a specific manner with a union, so I think you run into the same problem.

Making a library more portable in C usually means making the code an ugly mess of macros. So, first decide how much time and code clarity you want to sacrifice vs. the systems you want to be able to run it on. I have a large scale personal project data encoding library that I never finished in part because I tangled myself up in trying to make it 100% defined behavior C code. The world only has 3 major compilers: gcc, clang, and visual studio. If your code works on all 3, and its a hobby project, that's probably good enough. There are also vanishingly few big-endian systems left, aside from some embedded ARM processors. Also, declaring :62 will be a compile error on a 32 bit system, so that's maybe your biggest portability concern? But again, 32 bit is either old or embedded, so maybe not worth worrying about.

I believe that to make this portable to big-endian or 32 bit, you would need to make a macro to access the pointer and flags. Then you need to detect the endianness in preprocessor directives and set the macro to either a shift or a mask.

I also find that questionable. The compiler is allowed to pull a bit field from low or high bits (i.e. not specified in the standard) and it might be further affected by endianness.

This code is assuming that on little-endian, gcc pulls 62 bits from the low bits of the word, and on big-endian that gcc pulls from the high 62 bits of the word. It might actually be what gcc does, but I don't think any of that is guaranteed.

As I understand it, prions are just an ever-present rare tiny probability of a cascading malfunction of your physical composition. They are rare because they need to be, in order for a biological system to survive. (any biological system that had a high probability of prions would die off) They can never fully be eliminated because your body is built on probability, not mathematical certainty. Most organisms live less than 100 years, so the probability is good enough not to affect species survival. As long as young organisms don't eat old organisms, the chances remain low.

Another way to look at it is that the combined lifespans of the organisms of a food chain are shorter than the time it would take for one mis-folded protein to be likely to occur and then also cascade to a degree that would affect the health of the top organism. Prion diseases only show up when you introduce a loop in the food chain.

Both are problems, but to me the biggest facepalm goes to log4j because anyone in their right mind should assume that log messages are untrusted input and should absolutely never have been parsed for control sequences. It's another prime example of Java over-engineering everything that should have been simple.

Well, yeah, maybe if you are writing ray tracers. The focus of Delphi was object oriented data structures (especially for UIs) and there isn't a lot that the compiler can optimize when the function is packed full of method calls, which is why UI in Delphi was nearly identical performance to one in C++. If you want vector math to run fast, those C++ compiler optimizations are a lot more important.

Just to clarify, my main point was the speed at which it would compile the code, which was an order of magnitude faster than anything else.

I'd say Delphi was one notch better than Visual Studio. The pascal language was more highly optimized and easier to parse, so the debugger was much snappier about popping up the tooltips to show you values of variables or F1 to jump into the help pages. I remember being especially disappointed with VS because they would spend hundreds of MB of your precious disk space installing the entire Microsoft Knowledge Base, and the hitting F1 on a code statement would bring up a mishmash of Visual Basic examples (while developing C++) for almost but not the right class. In Delphi, it always knew exactly what class you were dealing with and would open the correct help page before your finger was fully off of the function key. The help pages had been expertly written to show you the most important details first, and were easy to browse. Really, I'm surprised I don't see more people reminiscing about those help files. There was probably as much effort put into that as into the frameworks or compiler or IDE.

It was by far the fastest compiler I'd ever used. A full 10x faster than their Borland C++ compiler, which was faster than gcc. Delphi didn't do as many optimizations, but the compiled code had runtime performance within a few percent of C, and the lightning fast compiles were worth it for productivity.

It doesn't surprise me to hear it was written in asm.

> The folks that have a lot of money don't spend it. Out of all of Buffett's, Gates', and Bezos' fortunes how much is being spent 'productively' and how much is just sitting around collecting interest on interest. The velocity of money hasn't been doing much in recent decades

You seem to indicate they have lots of money, but most of their wealth is assets, much of which is ownership of their own companies. If they "spent" that it would mean selling pieces of the company to someone else, and they would lose power to make the sorts of decisions that made the company successful in the first place. Letting a lot of middle class people's retirement savings managers make all the board decisions for Microsoft is not going to provide the same level of innovation as letting Gates have a large vote. The only reason those stocks have any value at all is because of the size and market position of the company. There is no benefit in letting this form of wealth have "money velocity".

Maybe you left Musk off the list on purpose, but what he's "doing with his wealth" is trying to make humans a multi-planet race, and he literally doesn't even care what his company shares are worth to other people. Is it really "money" if he doesn't intend to sell it? His recent sale of lots of Tesla was only because he had options to buy more of the company and immediately sell it. (and now he'll pay a few billion in tax, on that, since it was actually income) Until he did that, all his "wealth" was a mental fiction invented by him and the hard working people in his company. The real money just moved into his account for the first time in a long while, as he drained your retirement account in exchange for the idea that they now have a tiny piece of control over Tesla.

Think of how dead they would be if the insulin didn't exist. The part of the topic of insulin relevant to a discussion of trickle down economics is whether the insulin could have been researched and invented without letting people become wealthy profiting off of it. The monopoly on insulin that happened recently is one of the evil tendencies of capitalism that needs curtailed with laws, but unrelated to supply-side economics.

In the case of insulin, it was in fact invented with nothing more than research grants and the promise of fame and nobel prizes. But it also took 30 years from the first hints of what might solve diabetes until they produced a drug for it. It's an open question whether that could have happened faster with a profit-motivated company pushing the research.

That pretty much describes perl, except for the co-processes. Probably in part due to Larry Wall initially setting out to make "a better awk".

Maybe so. for some reason I thought Python made it hard to modify a class after declaration. I might be thinking of PHP, or maybe I tested something on a C-backed object without realizing.

For what it's worth, Perl lets you freely mix C methods with pure-perl methods in the same object. I also don't think Python has an equivalent for Inline::C

https://metacpan.org/pod/Inline

Getting back to the Moo topic though, you seem to hate the idea of reading user-module documentation to use an object system, but I see that as one of Perl's strengths. Perl's native object system is nothing more than data elements (usually hashrefs, aka dicts) "blessed" with a method table, and the method tables are nothing more than a dict of methods and variables. And you can use user-written modules to generate those packages, and create whatever syntax you like with the user-written modules without depending on core perl to add features. Reading the @cached_property Stackoverflow pages, it sounds like the way to implement this has changed several times over the past decade of Python versions. Moo works as-is on all perls since 5.8, released in 2002.

The ability to take some basic mechanics and build on top of that is what I like. There are dozens of object systems available in Perl because people were free to experiment. Moose was the first one that gained a lot of traction because it solved a lot of common needs. Moo gained a lot of traction for solving most of the same problems while being much lighter weight. I don't think it's any worse to read the manual for Moo than to read the manual for the decorators that Python provides.

Interesting, I hadn't seen @cached_property before. I was expecting you to have to muck around with __getattr__. The lazy attribute in Perl is simply one whose constructed value is deferred until the first time it is used.

For an example of taboo runtime changes, suppose you have one module which operates on a tree of data, like converting to JSON, and another type of object within that tree which does not have a built-in serialization to JSON, like DateTime. (there is really no way to universally serialize a DateTime to JSON because JSON only supports strings arrays and objects, and representation of dates will be application-specific). Perl lets you temporarily inject a method into a class for the duration of a scope, in this case the TO_JSON method which the JSON module looks for:

  sub export_as_json($data) {
    local *DateTime::TO_JSON= sub($date) { $date->ymd };
    JSON->new->convert_blessed->encode($data);
  }

After that scope, the DateTime package is restored to normal, without a TO_JSON method. How would Python solve this problem?

I didn't say you couldn't, just that the 'nonsense' is actually quite nice to use in practice.

Lets play Rosetta Code for lazy attributes:

  package Something;
  use Moo;
  has hostname => ( is => 'lazy' );
  sub _build_hostname { chomp(my $x= `hostname -f`); $x }

How would those look in Python or Ruby?

Meanwhile there are many things not on that page which Perl can do and Python and Ruby can't. (most related to taboo runtime changes of global state which are not recommended, but come in very handy when debugging)

And yet, the “nonsense” you see is the object paradigm I love the best out of any language I’ve ever used. It’s what keeps me on perl instead of moving on to other more trendy (and restricted) languages.

WordPress, Drupal, Magento, Joomla, OpenCart and lots of other open source community CMS and online web-store type things are built on it. Sadly it will never die because it has Facebook pouring money into it.

The class/package system is actually my favorite part of the language, and the reason I put up with the syntax warts. It goes one step better than JavaScript by putting methods and attribute storage into separate namespaces, and supports multiple inheritance, and lets you modify the method tables on the fly.

I like your analogy. But the more accurate statement is that perl has a fraction as many cows as it once had, but still more cows than other not-dead languages. It still gets more daily uploads to CPAN than Haskell gets to hackage.haskell.org packages, for instance.

Counter anecdote: the last traditional forum that I have any interaction with was so plagued by spam that they turned off registration and the new registration system is “send an email to the admin asking for an account”. Needless to say, they aren’t a growing community anymore. They also don’t use SSL because none of their admins are fluent enough to set up LetsEncrypt. Don’t forget that lots of non-technical or less-technical people like to have forums too.

Open this code side by side with the source code for Cyrus IMAP, or Perl core, or libssl, and then scroll through them. You will be enlightened.

In short, any code that is intended to work on a wide variety of systems is usually littered with conditional compilation directives and macros that make the code extremely difficult to follow without a extensive study of the author’s “setup”. This is because to compile/run on a wide variety of systems, you actually need wildly different C source code, and what is written in the C source file ends up being more like a template for a program than the actual program.