erlkonig

Since when does Microsoft owning a thing actually improve that thing?

Someone should send this doc to papajohns.com, which has overcomplicated their website to the point it doesn't even work in Firefox anymore.

Almost impossible, it depends on how fast they're being generated and the precision of the timestamp. The real problem is two years later when someone finds and removes that usleep(10000); /* sleep 10 µs */ that was the hard speed brake needed for the UUID generator, and suddenly duplicate IDs start showing up a few times per day or something similar.

I keep telling the dev teams I'm on that with enough data points, all those random numbers will (probably) eventually collide, and *then* we'll see how robust their software really is. At least your database flagged it, and hopefully nothing major exploded.

And yet, plenty of experienced devs, including team leads and CIOs, are convinced it's impossible. As in, they absolutely don't write code to deal with the condition. So a bad RNG can randomly destroy the system far sooner than expected at any time, and it won't be noticed, caught, re-genned, or anything, with concurrent corruption being entirely possible. They're fine with it. I feel like these are the same guys who don't check to see if malloc() succeeds.

I like to ask them, "If it's impossible, you're using too many bits, right?". I haven't talked any of them into hedging with a brownian motion detector, or a lava lamp or something for better randomness yet, but I'm still trying.

I really hate it when the recommended install method is curl-ing some script directly into a shell, often as root. Especially since it's pretty well known that the remote end can tell whether it's going to a script or a file.

Quarkdown's page has this:

curl -fsSL https://raw.githubusercontent.com/quarkdown-labs/get-quarkdo... | sudo env "PATH=$PATH" bash

And… yuck. And that ".sh" is kind of annoying all by itself.

GoDaddy proved themselves corrupt forever ago, grabbing domains their customers didn't pay for in time and then auctioning them back to those customers for massive markups. There's a litany of terrible things they've done.

My main domain is still with nic.ddn.mil / rs.internic.net … i.e the travesty of itself today, networksolutions, which once had the ethics to only give one domain name to each physical site so as to make sure future generations could have them. That fled the moment some pharm company attempted to buy about 90 domains at one and the greed set in. But the same process they failed to improved for a decade or two after getting an income stream is still considered more reliable that GoDaddy.

GoDaddy is corrupt, the joke everyone already knew who was in the know.

This is happening in Colorado too, meaning it could be part of a national push:

Colorado Senate Bill "26-051"

The actual bill and links to its two sponsors Matt Ball and Amy Paschal.

    https://leg.colorado.gov/bills/SB26-051

    https://leg.colorado.gov/legislators/matt-ball

    https://leg.colorado.gov/legislators/amy-paschal

It puts the infrastructure in place to do all of those things if a future(?), authoritarian regime wants to.

* It also reveals that visitors to any site are children, compromising their privacy and opening them up to targeted advertising

* The data will undoubtedly be added to the accumulated, traded databases so many services use

* The bill makes onerous demands of developers to consider other items that may suggest the user is actually in a different age bracket, like doing websearches for "toys" (child) or "toys" (adult) - which works what percentage of the time, exactly?

* And it's totally ineffective, since kids can look at porn anywhere they want, or internationally, regards of useless bill like this

The most egregious part of this bill is that:

* It legislates that if kids connect to a website, that website can query their age brackets (an "age signal"). This means their approximate age is revealed for kids-specific advertising, manipulation, or even sold to a pedophile group.

A DEVELOPER SHALL REQUEST AN AGE SIGNAL WITH RESPECT TO A PARTICULAR USER FROM AN OPERATING SYSTEM PROVIDER OR A COVERED APPLICATION STORE WHEN THE DEVELOPER'S APPLICATION IS DOWNLOADED AND LAUNCHED.

Basically SB 26-051 creates a mechanism that can be used to harvest the data that certain users are kids and then sell that data to anyone who will pay for it.

Data like this is traded internationally, which makes it tragic that elected lawmakers would waste time pushing a bill whose only mid-term effect would be making Colorado less attractive to developers and software companies.

The irony is that normally your kids would have been protected, by standard practices, from having their age exposed. This bill reverses that, putting your children at more risk.

The bill also would force many devices to provide age bracket data that are surprising to most people, because this part:

"DEVICE" MEANS ANY GENERAL-PURPOSE COMPUTING DEVICE THAT CAN ACCESS A COVERED APPLICATION STORE OR DOWNLOAD AN APPLICATION.

... means anything with Internet access and storage. This includes smart televisions, thermostats, tablets, smartphones, smart watches, some fitness tracking devices, some smart toilets, and so on, all potentially reporting your activity on demand, even if that back-end service has nothing to do with porn.

The bill is also poorly structured. Clearly it's intended to focus on services like app stores (Android, Apple), but by attempting to integrate support for this into operating systems, makes it available to hostile actors for any purpose worldwide. Further, it requires developers to guess whether other available information on a user might mean they're really in a different age bracket, exposing them to fines of $2500 to $7500 per minor "affected" (note: "affected" is not defined in the bill). The exemptions give blanket protection to developers working on for-internal-use software, but give no exemptions to recreational programmers. non-profit personal software, university projects, and so on, casting a chilling effect across software engineering generally.

Lastly, the bill is ineffective. Most of the web runs on Linux, a coöperative international effort, nominally controlled by one man in Finland. There is no chance of this bill's mechanism being implemented in this context. Nor will other developers be especially interested in rewriting software for this Colorado-specific bill. Further, the kids supposedly being protected from all the Colorado native porn sites would just web-browse to nearly any porn site and be outside of Colorado anyway, if not outside the US entirely.

These sponsors aren't alone. Most elected lawmakers are equally bad at technology and protecting democracy from the threats that come from chipping away at privacy protection. Bills like this appear in other states all the time, despite being toothless, easily circumvented by kids (who trivially circumvent even face photo hurdles), or radically compromising the privacy of adults (like this one).

There's also the long game, where these sometimes Democrat-led bills in various states could eventually see a much deeper-reaching federal one, where, instead of a "age signal", the user's computer must send an "ID signal", allowing all personal interactions with the Internet to be tracked, analyzed for political and other biases, and used by backbone firewalls to control exactly what people are allowed to read. Very handy for a dictator who might want to block off "fake news".

This is only a hypothesis, but one has to wonder whether sponsors to such bills even care if the bills work or pass, since either way they still get to claim they Protected the Children! even though the bills themselves violate privacy for everyone, often cause websites about breast cancer to be censored, or pave the way for authoritarian control - something this one stands out for. The only thing really surprising is that this bill wasn't sponsored by MAGA Republicans deliberately to add another paving stone to the road to national censorship.

I urge everyone to get in touch with other Colorado representatives to call for a fight against this travesty of a bill. Further, I would excoriate the two sponsors by email and phone, and tell them now that you will not reward this sort of juvenile lawmaking with your vote. Lastly, tell other people about how Matt and Amy plan to strip away their privacy in a way that puts children more at risk than doing nothing.

While XML was imperfect from overcomplication, JSON is imperfect by falling short of even basic database use, and somehow despite its alleged simplicity it manages to be unstandardized almost as badly as Markdown. JSON and YAML both fail to have comments that survive processing, something it's easy to regret since XML does have comments that appeared in the parsed objects.

A saner subset of XML, possibly run through some over-caffeinated developers to lighten its redundant syntactic feeling, would have given us something FAR better than JSON's failure and YAML's gratuitously hypercomplicated syntax.

Developers Are Stupid - developer.

XDG doesn't handle complex environments, especially not heterogeneous computing environments. Something long the core strength of Unix is acknowledged by XDG and then left utterly unaddressed. Without this, the "standard" is as much an impediment as an aid.

It's amusing that modetc goes through all this effort to twist dotfiles into the XDG half-solution, and here I am using symlinks through /dev/shm/xdg/* to warp XDG into sort-of working in an actual heterogeneous environment.

Because XDG by itself is a failure beyond trivial cases.

A while ago, I just wrote a filter to be able to paste markdown into a <name>.smd file, and an Apache filter to autoprocess them much like any other filter (and a <named>.smd.meta for title info and some other metadata).

This makes it super easy to write something cool on Reddit or whatever, then just paste the markdown into an index.smd file in a new directory (named meaningfully) and poof it's in a webpage.

The core of all of it is a /var/www/cgi-bin/markdown-to-html program centered on:

    python3 -m markdown -x codehilite -x fenced_code -x toc

It's enabled in my ~/www/.htaccess of all places:

  # This works, with setup in /etc/apache2/conf-enabled/mod-ext_filter-adds.conf
  AddType text/markdown .md
  AddType text/markdown .smd 
  AddOutputFilter markdown-to-html            md
  AddOutputFilter markdown-to-shtml;INCLUDES smd

Much easier to just edit markdown (index.smd usually) and reload than reconvert, and that filter above lets you include arbitrary HTML too, critical to deal with markdown numerous weaknesses.

I just hate that (1) you can't nest anything into a table (2) it's different everywhere.

Restructured Text is much more capable, and yet here we are, still using Markdown.

My markdown pages often also have HTML in them, I mainly use Markdown so if I decide some overlong thing I wrote on Reddit actually doesn't suck, I can copy-paste it into a webpage, and my web-server's .smd handler does the convertion. Lowest common denominator. :(

Fine advice overall.

Except:

Don't put suffixes on command names. Don't. It's a DOS thing that has no meaning in Unix. It confuses users. It breaks hiding implementation details. It encourages users to do the wrong thing. It makes changing what language a script's in have a ripple effect of breakage across everything else that uses it.

Don't do it.

The general movement of UI paradigm has been from one tech to the next with a focus on backwards compat. Almost amusingly so at times, but this is how all the earlier users and use cases can most easily progress. E.g.

* hollerith cards and sundry + printer * printing teletype * dumb (video) terminal * smart (cursor addressable) terminal * images of smart terminals * images of smart terminals with color (businesses resisted color for years) * ... ?

And in the meantime we have an evolution of support for modelling things visually and working with more descriptive protocols - or even function-defining protocols to raise the abstraction chatting with the display server in realtime. In this, "abstracted" means something that can be sent over the network instead of using a local buffer. These are in a less strict order than foregoing...

* text, color plotters, VDST, and all that other old slow stuff * [skipping a bit up through bitmapped greyscale graphics] * bitmapped color graphics * abstracted 2D graphics (-> W and X) * abstracted 3D graphics (OpenGL + GLX) * dynamically client-extendable remote graphics servers (NeWS, mostly 2D) * ... ?

So here I am, waiting for the next stage in these. Hypothesizing that finally we'll get something with 3D abstracted, network graphics (display lists in GLX but accelerated with something like XCB?), where the primary display coördinate space is (x, y, x) instead of (x, y), where the client can push some code to the remote server and raise the abstraction on the fly, finally. Where maybe we'd be able to permission the objects in that space and share it among users live. Where the 2D apps would be inside the 3D space instead of the other way around. Something for the 2000s instead of familiar abilities provided in 1990.

But instead, Wayland. Wayland, which is not backwards compatible with X. Wayland, which is 2D at its heart. Wayland, another 1990 era graphics system with a super thin offering of features for actual end users (not devs) which come at substantial cost in lost X features. Wayland, which resists the one user doing things we've long thought of as normal - in the name of "security".

Wayland is not what I've been waiting for.

I can't really enjoy an article on CSS where the third thing he does is to override the USER'S PREFERRED FONT SIZE.

Arrogant.

But not as bad as those jerks that use smaller and smaller, progressively lower contrast text as the actual content gets more important. Huge readable repetitive headings, microfiche gray-on-gray for the stuff that mattered.

<tirade style="justified">

F*k systemd, and systemd-homed along with it.

Their docs don't even mention homes mounted over NFS, or LDAP managed users. This is the same sort of pathetically marginal garbage that damns Snaps, which somehow think that large environments put all user directories in /home - even that that is NOT a standard and doesn't scale worth a damn.

Systemd is a curse, the TRON MCP that doesn't even seem have a system for alternate solutions to compete. Before systemd we saw a more lively environment of alternatives for each service area, but systemd strangles this with a collection of mediocrities, and lack of foresight.

Looking through the doc at https://systemd.io/HOME_DIRECTORY/ shows a entire webpage built of ideas many would rightfully reject, some defy standards, some defy common sense, and best practices, fail to scale, add arbitrary constraints, or have other problems.

I've been a sysadmin at large sites before. systemd-homed looks a lot like unusable trash.

</tirade>

This whole issue just seems so pathetic. PostScript and DPS, notably NeWS, have device-independent scaling from the outset - you can completely omit even mentioning pixels, even though they're 2D. Wayland braying on about scalability here just highlights how they don't even understand the game.

Going to OpenGL is a nice tactic, since OpenGL doesn't give a flip about screen coördinates anyway.

I miss NeWS - it actually brought a number of great capabilities to a window system - none of which, AFAIK, are offered by Wayland.

Using abort() every time malloc and kin fail isn't really satisfying anything except the idea that the program should crash before showing incorrect results.

While the document itself is pretty good otherwise, this philosophical failing is a problem. It should give examples of COPING with memory exhaustion, instead of just imploding every time. It should also mention using "ulimit -Sd 6000" or something to lower the limit to force the problems to happen (that one happens to work well with vi).

Memory management is mature when programs that should stay running - notably user programs, system daemons, things where simply restarting will lose precious user data or other important internal data - HANDLE exhaustion, clean up any partially allocated objects, then either inform the user or keep writing data out to files (or something) and freeing memory until allocation starts working again. E.g. Vi informs the user without crashing, like it should.

This general philosophy is one that I've seen degrade enormously over recent years, and a trend we should actively fight against. And this trend has been greatly exacerbated by memory overcommit.

Most of both this article and the discussion is covering the simple case of home on a local hard drive, rather than the more interesting real-world situations with network-mounted home directories and multiple different HW/OS architectures you'd want to be able to have handled transparently. Which is fine.

For more... interesting network scenarios, it can be helpful to construct some variable, say, $HOSTABI, that includes tokens for both hardware and OS.

$ echo $HOSTABI x86_64-ubu-2204

Which can then be used inside architecture-influenced variables like ARCH, LIBRARY_PATH / LD_LIBRARY_PATH, PATH, as well as inside the user's own installation system (makefiles, etc) used for anything the user compiled. Great for just installing some new hw/sw combo, mount home, cd into "~/src" or equivalent and run "make install", and just get all your own code recompiled and installed for your new architecture.

This is a microcosm of what sysadmins on heterogeneous networks do, mostly for different hardware architectures, although this was a much more common situation in earlier years than more recently where Linux has taken over even more of the corporate/research world. I've found it pretty useful even at home, where I'm using my one home directory across my systems' different installations of Linux with different library requirements (although I should probably sell that SGI Onyx/RE - IRIX not Linux - that Wing Commander III was rendered on).

My home directory is usually populated almost exclusively with dotfiles and some threescore subdirs with 3ish-letter names like doc/ etc/ fun/ (I'm a gamer) git/ iso/ job/<site>/<recursehere> lib/ man/ pub/ (packages of my own programs) sbin/ src/ steam/ (yep) tmp/ var/ (notes, logs, etc) vr/ ... and so on.

It seems to work out alright. Contains about half a million subdirs and 4.2 million files. ;-)

Putting any personally important email account in the hands of some huge corporate provider is pretty much always a recipe for eventual problems.

Although big companies also have some leeway to steal domains (and the associated email addresses) from small companies and hobbyists, so just trying to keep your email to yourself doesn't solve everything.

Of course, that nearly every domain anyone wants is taken already is also a bane on us caused by a big company - Network Solutions, the privatized descendant of the Internic, as they realized their old rule of one entity / on domain didn't have to be followed, and blithely made their first evil sale of 80-odd domains to some household name drug company that wanted a domain for each common ailment or something. The idea of saving readable domains for future generations went right out the windows once someone waved money under their nose (and they didn't use that money to improve their UX for over a decade), and now virtually all registers are shills for shoving domains you don't need down your throats. Ugh. At least the old Internic had ethics.

Just like Google had the do-no-evil motto - somehow I doubt that's still a thing. Good luck getting a lost email account of them - they didn't give my Google phone number back even though the system still knows it's mine.

A bit off topic at this point, sorry.

However, that Apache situation, multithreading *like* things together (request handling), is a more reasonable act than say, turning all of PostgreSQL into a monolithic process. PostgreSQL is a much more heterogeneous system than Apache, with potentially more interesting ways to lock up than Apache with its rather simple overall mission.

Sure it sounds interesting to try a branch of pg with, for example, just the sessions being multithreaded - but then how DOES one forcibly stomp on some session that has grabbed some critical lock without crashing other users' sessions? Killing off a session's thread inside of a MT'ed session handler without putting any other threads at risk would be the first problem (and an admin is likely to use "ps -Lef" to find the thread ID and then "kill"). Many MT programs I see lose their little minds if a thread is killed from outside.

Going too crazy with threads can also cause performance issues, since there is overhead - just less than for processes - around thread creation/switching/etc, and is why thread pools are common. There's a short article about this at:

    https://stackoverflow.com/questions/5961536/what-is-best-a-single-threaded-or-a-multi-threaded-server/5964238#5964238

There's some theory about how multithreading to handle a bunch of fds versus using poll / nonblocking I/O in a singlethreaded solution being equivalent at some level in computing science, but skill sets tend to matter more in practice.

This is a pretty good page on the options in general, though dated (anyone already know of a newer equivalent to it?):

    http://www.kegel.com/c10k.html

I feel sure work has been put into making kernel support for both MT *and* the poll and nonblocking I/O models more efficient since then. :-)

You can usually find developers interested in any fashionable approach to a problem. Change is fine. What improvement, specifically, though? Adding multithreading is not a functional improvement in and of itself, but more the opposite. MT should be used when a specific, important functional gain can be realized through no other approach.

I'm not trying to win an argument or anything here, I'm just highlighting from my and others' experiences that multithreading is a tradeoff not to be made casually. It makes some things faster, especially if not I/O bound, but it also increases dev and debug cost, and reduces the number of developers who can assist. That downside tends to permanent.

[I wrote this mostly imagining the idea was about converting the entire Postgresql service to a single monolithic process. I'm not a fan so far. If is actually around coalescing like processes down to a single multithreaded process, that's more reasonable but still comes at a future cost - and whether pointful is still a question]

Converting code into multithreaded code tends to make it harder to test and debug FOREVER, as well as being more limited by default for certain system resources than a multi-process solution. Viewing and managing threads from the outside is harder, and killing a rogue thread is much more likely to crash a MT solution than killing a process in a typical resilient MP solution. Above all else, I need a database to be utterly reliable (or as close to it as possible) - including being able to back off in a mature fashion in cases of memory exhaustion (I have overcommit disabled to restore classical memory handling, i.e. malloc() can fail), and file system exhaustion. MT throws a wrench through most of the workings of a complex program, and unless some specific gain can be identified that compensates for adding complexity and fragility to virtually any change going forward, then... um... why? I read a bit "well, the other guys are doing it" handwaving:

    "Other large projects have gone through this transition.    
    It's not easy, but it's a lot easier now than it was
    10 years ago. The platform and compiler support is
    there now, all libraries have thread-safe 
    interfaces, etc."

But that isn't a functional gain. And:

    "I don't expect you or others to buy into any
    particular   code change at this point, or to
    contribute time into it. Just to accept that it's a
    worthwhile goal. If the implementation turns out to
    be a disaster, then it won't be accepted, of course.
    But I'm optimistic."

But this is NOT a worthwhile goal. Fun, perhaps. Diverting or challenging, perhaps. A disaster, quite possibly. But without identifying a goal that can only be achieved by walking into the multithreading pit, the project is a waste of time for end users. Possibly a growth experience for the experimenters, regardless of whether successful.

Each of your 3 foundational knowledge points will never be used by certain branches of computing. There are scenarios where none of them will be used, so it's hard to truly call them foundational. Filesystems are a key discipline you left out, for example, but it, too, isn't quite foundational.

The foundations are things like (this list should not be read as being comprehensive):

* Formalized languages

* The implementation, all the way down to the hardware, underneath those languages and how to bridge between them (this is far too frequently omitted unless it comes up in some 1 hour credit C course - and lately we're seeing C replaced with C++ courses trying to pretend to be abstract, making them pretty pointless to teach at all)

* Algorithms

* Complexity, Big-O notation or equivalent, computatibility in general, and mapping underlying algorithms to different problems

* The reality of just how different an implemented language and platform is from the abstract idea of one - limitations on sizes, errors, failures, etc, all the things that complicate the lives of a theorist trying to do real work

I'm especially annoyed by the C++ classes - said language is a massive cognitive load to inflict on students, and a huge, vocational distraction from the theory and concepts a degree SHOULD be teaching. A better course spread would be some machine language, C, LISP, Smalltalk, some (modern version of a) goal oriented language like Prolog or KL/1, something with intrinsic multiprocessing support, and one that is essentially distributed, and so on. Languages that demonstrate the breadth of what a language can encompass, rather than grinding students into the bottomless pit that C++ has become.

I do agree that these all are relevant: databases (by implementing one, with attention to ACID, but with a lot of assumptions about reliability given and highlighted), concurrency (both with a language that does it intrinsically, and in one that doesn't), and network programming (at least three totally different approaches here: intrinsic to a cluster environment, intrinsic to the language, and implemented via libraries like in C). However, these ideas are not each important enough to count as core.

The point of a non-vocational, classical degree is to be able to understand the field and to be able to create tools - including new ones. The higher the degree, the more important it becomes to be able to extend the field. The objectives (in part) of a classical degree are what I've described, with the goal of producing synthesists and creators within the field of computer science.

In the vocational education, the grads will hit the ground ready to write code using existing libraries and tools, perfect to drop into some project underway to use what they've learned to tie everything together. But they'll be pretty naïve when it comes to creating them, and generally unaware of ideas that fit the tasks better and just need to be pulled in. Have them learn whatever language is the current fad for a couple of years, and train them in all the current things. But they'll have a harder time as the tools shift underfoot.

Some things bridge both the classic and the vocational. Source code control, for one (UTexas CS basically requires knowing git, for example), all the tools' varieties we take for granted to share work, google, communicate, and try to make AI write our homework or job assignments. But the classes for git should be quite different in a vocational versus classical curriculum.

Basically, given what I've heard from former students at various places (and I taught for a decade myself) I see many colleges leaning towards teaching a vocational CS curriculum and pretending it's classical, and this damages the field overall. At the same time, I've seen overly theoretical degrees in CS that I think are also a problem, in a different way, if the students were led to believe they'd be able to actually create software when they were done.

The most pathological example I've seen is a professor at the University of Texas who was trying to teach his students IPC using C and Unix as the demonstration environment (essentially a classical lesson). However, since the professor's awareness of the implementation was too limited, he was using examples with the wrong paradigm - FIFO pipes - instead of sockets. The result being that the examples only worked for processes with a shared parent proc. This undercut the objective so badly that the students were missing the point of IPC, since they could have had a single process produce essentially the same results as the example, and were getting no payoff from the FIFO aspect. The professor's limited vocational grounding was producing students who were failing to understand both the practical AND theoretical.

So it's not just a case of a poor curriculum poorly serving the students, the professors themselves are suffering from the problem of being too polarized between theory and practice. The problem needs to be viewed as endemic in some colleges and I'm not sure anyone's really talking about it enough.

The big clue here, is that if we allow generated content to be copyrighted, then some asshat company will just generate All The Things (within, say, a given space) and copyright them (likewise for trademarks and patents, which could be much easier to exhaust within defined spaces). Combined with the lifetime of companies and the preposterous copyright extensions granted to them, swaths of human-generated work could be excluded from copyright, blocked by some hidden trove of copyrighted machine output. Especially bad if someone manages to copyright everything that could be generated by some AI.

Gitlab has been cursed by a marketing team that seemingly just can't imagine having mixed licensing levels. At a side effect, organizations that would adopt them at the low (free) tier (or just above) for the whole company, a higher tier for devs, and max tier for project management, etc, just can't. Instead they have to have separate gitlabs to cover the whole organization, which has a whole set of associated annoyances.

I speak from direct experience, at a company that had the mid level, liked the features, but was forced to eventually jettison them for the free tier to cut costs while broadening internal support.

And we reported this problem to them, this basic lack of a mixed tier system, something many customers want. But Gitlab can't seem to get it through marketing's head that being nearly everywhere is better than just running for few large companies. Running everywhere means that many devs would just bring along an expectation of having gitlab as a matter of course, spreading adoption like a beneficial contagion. Instead, any useful level is being priced into irrelevance from a smaller organization's perspective, something many devs will see at prohibitively expensive, and be the fomites for that perspective instead as they move between companies.

The result is terrible. Our company switched to Git on Microsoft Azure. Good job, Gitlab sales (heavy sarcasm). Hey, Gitlab management, have you checked to make sure your sales team isn't secretly taking kickbacks from Microsoft? (yes, I'm probably kidding, right?)...

At more centrally-administered sites, a user might not even have the ability to change an X server option. The idea of making a toggle via xset sort-of makes sense, but seriously, isn't the idea generally that you trust the apps you're running anyway. And doesn't a vastly different wrong number in some X call at least produce an effect that makes you aware of the problem (I know, that doesn't make a X server more stable...). It's just baffling to make something near-universally available less so. The next new CPU thing could be bigendian - or quantum, but who knows what byte order that would prefer.

It seems the 2015 Zuck is limited by what's familiar to him and utterly failing to see the potential of new technology. To him, VR/AR is just a realm in which to deploy the same apps, a market to capture, annex Unity to protect themselves (at the probable expense of everyone else - glad that didn't work out).

The idea of a large, shared environment as a platform for heterogeneous development seems to have never occurred to him. No vision.

My theory is that this same Windows experience is also how so many joined the command-with-filename-extension cargo cult. But unix and windows work differently, and the approach does NOT port.

No, this is pretty meaningless unless sourcing in function.sh or something. If your script is short lived and doesn't have a work area (read/writing files), don't bother with cd. If it's long lived, the best default would be "cd /" or "cd /tmp" - sadly, since bash seem to mmap the script, this still doesn't free up the filesystem for unmounting. Python is different, and "cd /" is a good default for a long-lived program.

echo has long been unreliable. Even the built-in echo in the shells were unreliable in SunOS, because the shell would look at the binaries in your PATH and try to figure out whether to emulate the BSD vs SysV (IIRC) version of echo and then change what echo would do. So much for writing a single script (with echo) that would work for all your users on the same host.

This is why you'll see code like this: echo 'prompt: ' | tr -d '\012'

No other simple mechanism was portable at the time. Seriously portability-minded coders still use that line, because although the issue is finally dead in linux+bash (i.e. /bin/echo is enough like bash's builtin) - it's likely still broken in other Unixen out there.