There's a difference. It was a matter of principle for a Web site (not) to use pop-up ads or ads in general. It would be highly inappropriate for a large and successful business to have (especially pop-up) ads in their product (unless ads was their business).

Another aspect of ads from the early 2000: they were individually made for particular places, rarely generating any controversy. For example, I used to be a moderator on a forum dedicated to ActionScript, and we had a sponsor, who, basically paid our hosting expenses, and that sponsor had a banner in the header of the forum advertising lessons in Web design / programming. The banner was designed to match the overall forum appearance, it didn't track anyone's browsing history, didn't collect cookies... it was simply a big and fancy button linking to the sponsor's Web site.

The problems really started with the "media buying" waterfalls, i.e. the automated ad delivery. Ad agencies automated their job by providing customers with (semi-, but increasingly fully-automatic) ways to design their ad campaigns. In order to make these campaigns at least somewhat effective, they needed to somehow automatically reproduce the situation similar to the one I described having in the ActionScript forum: they needed to find a good match between the audience and the ad, but they had to cut corners because of the automation and resort to the unsavory mechanisms of tracking users' behavior. The decrease in quality had to be compensated for by increase in quantity. And that's how we got here...

I believe that the target market for this equipment is small / medium size enterprises that need a solution for local storage of whatever information they process in their day-to-day operations. So, they won't have a system administrator on staff. They would rather try to assemble their computer system themselves or pay someone once to put things together. In this context, having a pre-built component that one can plug into the larger system is what customers would be looking for.

It's similar to the days when buying a PC would involve either finding a friend who could read the specs from the computer shop, make a list and assemble the PC once all the components are bought, or you'd buy a build from the shop (with some extra markup for the service). And today most PC users have moved on to laptops if not just even phones.

Most people will use what's commercially available. Today, most NAS users won't have an old PC case with HDD mounts laying around. They will have to buy something, and that something will likely be a pre-built NAS, the kind this article is written about. And similar to how laptops are a form of enshitification of desktops, these NAS boxes are too. Removing modularity drives the price down, but also doesn't allow the users the ability to repair and to study the product they own.

People aren't "crazy" about buying pre-built NAS boxes. It's what there is, they buy what's available.

You missed the point the author really complains about: soldered in memory chips create a single point of failure.

What you quoted needs to be seen in the context of what author calls "increasing media demands". I.e. the author believes that while the way the system is configured might be OK today, it won't be OK in the future.

Memory chips failing to me sounds like extremely bizarre fear. Memory has been extremely reliable for long time now. It is much more likely any other component on same mainboard failing than memory.

It still makes it a single point of failure...

Every single component in NAS which breaking stops operation is single point of failure. So should those all too be socket mounted?

That's a tautology...

But, maybe if I try to salvage what you were trying to say: while failures are a fact of life, higher-quality products will try to minimize and mitigate more of them. Making more components replaceable, is the direction to improve resiliency, and therefore quality of the system. It could be impossible or highly impractical to make everything socket-mounted, but making more components socket-mounted is certainly a way to make a better product.

The question about designing elevators used to be the mainstay of programming job interviews. I had an annoying interview where I was asked, for the umpteens time to design an elevator. I already made up my mind at the time, knowing I'm not going to work for the company, but decided to have a... unexpected approach.

So, for instance, I didn't measure the elevator's efficiency in the wait time. I included (weighted) travel time. I assumed LOOK algorithm was used. And then when I tried to calculate various outcomes for different trips I suddenly realized that elevator's efficiency and fairness seem to go different ways.

Without trying to reproduce my evaluation system, here's my finding in fewer details: if you have two passengers, one going from the ground floor to the top floor and other joining for the shorter ride down in the middle, then the elevator that makes a "detour" is more efficient, but it hardly seems fair that the passenger traveling ground floor to the top should go even a single floor in the opposite direction.

Somehow, until that point, I lived with an illusion that the most efficient solution to a problem must be the most fair to every participant. Discovering this counterexample sent me on the "tour of discovery" of ethics and different philosophers who contributed to it... and while in the end it made me none the wiser, I'm happy to have discovered this field.

Surprisingly, I've met non-programmers who easily learned languages considered "strange" or difficult to understand by professional programmers (Forth is even somewhat popular among astronomers, but I've also met people using Prolog for their programming needs, even J).

I've worked quite a bit with scientists who mostly use Python for their programming-related tasks. To me, it seems that the reason to work with Python has very little to do with the qualities of the language, rather the tools and the community around it. There's nothing specially intuitive or helpful about Python when it comes to doing scientific stuff, not anymore than, say, in PHP or Lua etc. languages from the same general category (which we don't see used in the same setting). It's the libraries / tools like NumPy and Jupyter that make the difference.

From just looking at EYG, I can't tell if it's a good match for the problem or not. But, really, the language design doesn't seem to play an important role in this context. If it somehow manages to win popularity among the people it's trying to engage -- great! But, unless one has an army of "evangelists" and the marketing budget rivaling GDPs of smaller countries, the success seem to be completely random and unpredictable (with quite low success rate).

> So let’s say you want to create a program that doesn’t have bugs. How should you do it? Fundamentally the only way to make sure a program will always do what you want is to understand everything it can do. But there’s a kind of paradox implicit in that: if you can really understand everything your program can do that basically means the program is doing something computationally reducible, and you probably in the end didn’t actually need to run the program with all its steps to get the result you wanted.

So... he has this "strange" idea of what makes a program useful... I wonder what does he think about a program that displays system time? Totally predictable! So, should it be just replaced by the output?

On a more serious note, at least from a perspective of a system programmer, vast majority of programs don't do (intentionally) this kind of nodeterministic stuff. They are more of a complex way of displaying information obtained by the sensors, or a way to cause the physical parts of the system to change their configuration. They are totally predictable, yet they still are absolutely necessary for the computer system to function.

Yeah... in the place I worked, for a while, they didn't have a package index for Python packages (similar to PyPI), so, I wanted to write one. At the time I had a love-hate relationship with Ada, so, after trying to do something with Python and thinking how much resources I would have to ask for and whether I'll need load balancing etc... I checked what Ada's (somewhat unfortunately named AWS...) would need to be used as that kind of index. Suffices to say that I wouldn't need any of the "reverse proxy" servers, no caching, no load-balancers... It would be fast enough to service a company with thousands of employees on a very modest h/w setup.

Using Django is like trying to walk on a highway, with a crutch. Even though it has some convenience features, it's just so impossibly slow you would have to invest a lot of engineering time and resources to mitigate that slowness.

PowerShell is a bad choice for the system shell because it's too complex. I'm not trying to justify all the quirks of Unix Shell, but minimalism is a very important feature of such a tool.

Another important feature of a tool like this is the ability to tolerate errors: I can't imagine a Linux today that would be able to even boot if the shell was extra pedantic about errors. A lot of mostly irrelevant things routinely fail on boot and during normal operation. Stamping them all out is an arduous... well, basically, an impossible task for practical purposes where releases are expected to come on time, where users may manipulate configuration in gazzilions of unpredictable ways.

PowerShell is just another language in the same box with Python, Perl, Ruby and many like that. It's not a good language, if you decided to reach for that box. Probably not the worst either.

System shell, however, isn't meant for writing entire applications. Writing applications with elaborate command-line interface should be left to languages that can properly address this problem. PowerShell is trying to be there, but it doesn't hold a candle to its "older brothers" who can, indeed, design a very robust command-line interface, often using a dedicated library for it.

PowerShell appeals to the novice crowd who are very enthusiastic about automatic checks in their code: the benefits are on the surface, the downsides are difficult to assess. This is in line with other Microsoft software products / languages which target novice programmers by implementing as many as possible of the highly-advertised features without regard to the overall usefulness of the product (think about C# or MS Office suit etc.)

> System shell, however, isn't meant for writing entire applications.

Programmable shells are, in fact, for programming. That posix shell syntax makes it impractical for meaningfully large scripts is something you just accept. And, realistically, it is something you have to accept.

Minimalism isn't why posix shell syntax is bad. For example, awk and jq are minimal but don't make the same mistakes.

Powershell was never designed to be your system shell (Windows doesn't really rely on one) but the main reason it can't be the shell is startup time, which rules it out of wrapper scripts. Its having lots of features might contribute to that but it's not the problem per se (being built on .net is the reason - that and startup time not really mattering on windows). Its lacking the syntax problems of posix shells is very much not a problem. Powershell's error handling is just fine, by the way.

The startup time of even pwsh is too slow to be usable in many scenarios.

PowerShell's not going to be the system shell on your *nix box but it wasn't designed to be. But your posix shell isn't the system shell because it's better. It's pretty much the ultimate expression of worse is better.

That's why there's an industry of alternatives without the faults, such as oil, elvish, fish, nushell. And why awk is so popular.

There are many programs that aren't applications. For example, databases. You wouldn't argue that because you can program in eg. SQL it should be able to make applications with a robust command-line interface, right? Same idea applies to system Shell. Its purpose is to expose the operating system functionality interactively and for ad hoc automation. It is deliberately made simple and therefore incapable of more advanced system programming because complexity creates problems in this particular domain.

For instance, consider that Unix Shell only has one data-type: strings. I believe this was a deliberate decision by its creators (or a stroke of luck). Compare this to languages s.a. original JavaScript with a handful of built-in types, or, even worse, modern JavaScript with user-defined types. Even though the language tries hard to supply default "solutions" to type mismatch errors, it doesn't work well, and sometimes, at all. Unix Shell is inherently incapable of type errors.

While in statically checked programs, or even dynamically checked ones with robust debugging tools types could prevent certain kinds of programming errors, in the mostly interactive programs types make no sense. There simply isn't enough code to generate the kinds of problems types are supposed to solve.

> Minimalism isn't why posix shell syntax is bad.

I never said that.

> Powershell was never designed to be your system shell

Parent wants to replace Linux system shell with PowerShell, that was the reason I replied in the way I did.

> Another important feature of a tool like this is the ability to tolerate errors: I can't imagine a Linux today that would be able to even boot if the shell was extra pedantic about errors. A lot of mostly irrelevant things routinely fail on boot and during normal operation. Stamping them all out is an arduous...

You seem to be implying PowerShell aborts on any error. That's not the case:

https://learn.microsoft.com/en-us/powershell/module/microsof...

No, I didn't imply that. PowerShell introduces many different error modes that aren't possible in Unix Shell because it tries to operate on structured messages, has a type system, has a bunch of built-in functionality for accessing various aspects of the system that in Unix Shell are delegated to external utilities.

My main issue with attempting to replace Bash with other shells is that they're often not installed by default on different Linux flavours and they don't/won't have the same longevity as Bash. Try running PowerShell on a 20 year old Linux system or maybe find out if there's some version issue with running an old script 20 years in the future.

Well said, esp. the last paragraph about the Microsoft strategy.

1. There are multiple levels at which things are hashed, signed and checked when it comes to Python packages. Eg. each file in the Wheel beside the RECORD file is hashed using SHA256. This hash is never checked :( You can also sign your packages (RECORD.jws anyone? Is that still supported?), but nobody checks that either.

2. There are hashes in the HTML served by PyPI. These are updated at the whim of both the index and the publisher. Even though they are checked by pip during install, they are worthless.

3. There are many ways to install packages that work around (2). Custom index server doesn't have to provide hashes, and pip will happily install that. You can install from sources, from a package you've downloaded somewhere, form VCS, you can build it during install, all without even prompting the user to confirm the very scary choices.

NB. I have no idea how do you make the leap from "adding files to release" to "not modifying the release". To me, adding file to release is sure as hell modifying it. Here's a very simple malicious example:

I release package "innocent" with an empty "scripts" section. Then, in the subsequent modification to this release, I add the "scripts" section with a script named "notebook". Now, whenever my user wants to run Jupyter notebook, they will call my "notebook" program, not the one from Jupyter package.

There are a lot of misconceptions here:

1. “Wheel” signatures (e.g. RECORD.jws) were specified but never actually implemented in any major packaging installer, to the best of my knowledge. In that sense it’s not really meaningful to ask whether they’re “still” supported, since nothing ever did support them unfortunately. The reasons for that are multifaceted, but a single easily identifiable reason is that they don’t solve the key/identity distribution problem.

2. The primary benefit of index-supplied hashing is for lockfiles. Specifically, they make lockfiles like uv.lock and pylock.toml useful/meaningful.

3. Is the source distribution problem, and is sort of fundamental to any packaging system that has any amount of dynamism in it. There’s a good argument to be made for reducing unnecessary dynamism (e.g. via wheels), but a nontrivial percent of Python users actually want this behavior.

Re: files: I think you’re getting confused about distribution files (sdists and wheels) versus the individual contents therein. You can’t modify distribution files on PyPI, you can only add new, unique ones. And this is now restricted to 14 days for each release.

1. There was a discussion few years ago to remove the signatures from the format at all. I don't know what the resolution was, that's why I don't know if it's still supported, as in is it supported by the specification or not.

2. Lock files are hilariously wrong in Python. They don't accomplish what they claim because the only tool that in principle could do that and that is actually used with Python deployment / development is conda, and to the best of my knowledge conda's environment doesn't support locks. All other installers don't even guarantee that successfully running them will produce an environment with all dependencies met. But, not only that, they don't prevent users from becoming victims of manipulations that happen index-side because they don't store the checksums.

3. "nontrivial percent of Python users actually want this behavior." I'm yet to find one. Most Python users simply don't understand how any of their packaging works and come up with absurdly bad ideas and "solutions" to their problems. They may tell you they want something in the same sense as a drug addict may tell you they want more drugs, but the "actually" isn't there. They "actually" don't know what they want most of the time.

> You can’t modify distribution files on PyPI, you can only add new, unique ones.

I just gave an example of how this modifies the package. Not sure what problem do you see with it.

That's the direction PyPI is going: https://news.ycombinator.com/item?id=49007291#49047014