My current position has implemented a toolchain that essentially makes debugging either impossible or extremely unwieldy for any backend projects and nobody seems to think it's a problem.
It's hard to see the benefit in letting every hardware manufacturer attempt to carve out their own little artificial interconnect monopoly and flood the market with redundant, wasteful solutions.
I am frankly wondering if this man believed in any of the things he was saying, or if he was being purely cynical.
The proposition in this article is extremely simple. Adobe Flash would have compromised the end-user experience on iOS devices, so it wasn't allowed into the walled garden. All the lip service he is paying to open source here reeks of PR bullshit. They are perhaps the worst offender, and the furthest removed from the idea of an "open web", of all the silicon valley companies.
Pretending that WebKit was an open source project born at Apple, for the sake of contributing to the open web or whatever, is straight up trashy. Besides this failure to attribute, one could argue that Apple needed to comply with the LGPL when they forked KHTML and KJS. I see no reason to believe that a fully original browser engine born at Apple would be open source.
Fascinating to me how Windows and Linux have cross-pollinated each other through things like WSL and Proton. Platform convergence might become a thing within our lifetimes.
I made a "long bet" with a friend about a decade ago that by 2030 'Microsoft Windows' would just be a proprietary window manager running on Linux (similar - in broad strokes - to the MacOS model that has Darwin under the hood).
I don't think I'll make my 2030 date at this point but there might be some version of Windows like this at some point.
I also recognize that Windows' need to remain backwards compatible might prevent this, unless there's a Rosetta-style emulation layer to handle all the Win32 APIs etc..
I think Microsoft will let Windows slowly die over the years. I am certain that at the strategy level, they have already accepted that their time as a device platform vendor will not last. Windows will be on life support for a while, as MS slowly corrals its massive client base onto its SaaS platforms, before it becomes a relic of the past. Beyond that point, the historical x86 PC-compatible platform lineage will either die with it, or be fully overtaken by Desktop Linux whereupon it will slowly lose ground to non-x86 proprietary platforms over the years.
The average end user will be using some sort of Tivoized device, which will be running a closed-source fork of an open-source kernel, with state-of-the-art trusted computing modules making sure nobody can run any binaries that weren't digitally signed and distributed through an "app store" owned by the device vendor and from which they get something like a 25% cut of all sales.
In other words, everything will be a PlayStation, and Microsoft will be selling their SaaS services to enterprise users through those. That is my prediction.
The inexorable process of using security as a pretext to enshittify your platform carries on. I don't believe there is a meaningful difference between Google and Apple anymore.
I used to work for a .NET shop that randomly wrote some automation scripts in bash. The expertise to maintain them long term (and frankly, write them half-decently to begin with) simply wasn't there. Never understood why they didn't just write their tooling in C#.
Maybe this will make it seem like a more viable approach.
Here’s the really annoying thing with powershell: it doesn’t have a module distribution model. Like, at all. A csharp script, on the other hand, gets NuGet out of the box.
It is reasonably unlikely that bash scripts are easily replaceable by powershell scripts.
Theres a fair argument that complex scripts require a complex scripting language, but you have to have a good reason to pick powershell.
Typically, on non-windows, there is not one.
Its the same “tier” as bash; the thing you use because its there and then reach past for hard things. The same reason as bash.
Theres no realistic situation I would (and Ive written a lot of powershell) go, “gee, this bash script/makefile is too big and complex, lets rewrite it in powershell!”
To this day, error handling in most Unix shells just sucks. Background commands, pipes, command substitutions, functions, if/while conditions, subshells, etc. are all "special cases" when errors are involved. You can make them suck less but the more you try to handle all the possible ways things can fail, the vastly more complex your code becomes, which the Bourne lineage languages just aren't ergonomically suitable for.
I think PowerShell was totally right to call this out and do it better, even though I don't particularly love the try-catch style of exception handling. False is not an error condition, exceptions are typed, exceptions have messages, etc.
The problem with PowerShell coming from bash etc. is that the authors took one look at Unix shells and ran away screaming. So features that were in the Bourne shell since the late 1970s are missing and the syntax is drastically different for anything non-trivial. Other problems like treating everything as UTF-16 and otherwise mishandling non-PowerShell commands have gotten better though.
Not an old hat. in the dotnet world for 3 years, bash over a decade. Agree with bash not being easy to maintain.
Argument about bash being always there breaks down quickly. Even if you limit yourself to bash+awk+grep, they dont work consistently across different bash flavors or across platforms (mac/win/linuz).
My approach now is to have my programs, in the language most convenient to me, compiled to a bunch of archs and have that run across systems. One time pain, reduces over time.
> Argument about bash being always there breaks down quickly. Even if you limit yourself to bash+awk+grep, they dont work consistently across different bash flavors or across platforms
IMO this is why Perl was invented and you should just use Perl. Bash isn't portable and isn't very safe either. If you're only going to use a couple of commands, there's really no reason to use bash. The usecase, in my head, for bash is using a variety of unix utils. But then those utils aren't portable. Perl is really great here because it's available on pretty much every computer on Earth and is consistent.
Except Windows, of course. You can install it there but it's plainly obvious it's in a foreign environment.
A lot of people focus on Perl's bad reputation as one of the first web languages instead of its actual purpose, a better sh/awk/sed. If you're writing shell scripts Perl's a godsend for anything complex.
Sure, but these days so is Python. And you've got a dozen other languages available after a single command. You wouldn't recommend using a kitchen knife instead of a chainsaw to cut down a tree just because it's already there, would you?
Bash has a huge number of footguns, and a rather unusual syntax. It's not a language where you can safely let a junior developer tweak something in a script and expect it to go well. Using a linter like ShellCheck is essentially a hard requirement.
If you're working in a team where 99.9% of the code you're maintaining is C#, having a handful of load-bearing Bash scripts lying around is probably a Really Bad Idea. Just convert it to C# as well and save everyone a lot of trouble.
> Bash has a huge number of footguns, and a rather unusual syntax. It's not a language where you can safely let a junior developer tweak something in a script and expect it to go well.
I'd say as someone who started with shell/bash in ~ 2000 to cater Linux systems, it's quote usual syntax and I believe that's true for many sysadmins.
No way I'd like to deal with opaque .Net or even Go stuff - incapable of doing "bash -x script.sh" while debugging production systems at 3AM. And non production as well - just loosing my time (and team time) on unusual syntax, getting familiar with nuget and ensuring internet access for that repos and pinging ITSec guys to open access to that repos.
> let a junior developer tweak something in a script and expect it to go well
let developers do their job, writing bash scripts is something extraordinary for dev team to do, just because - where they expected to apply it? I can imagine "lonely dev startups" situations only, where it may be reasonably needed
>Dotnet is a pig with its dependencies by comparison.
Dotnet with all dependencies you will get in how much time? In like 6 minutes including all the preparations? So the difference between "already there" and dotnet - is 6 minutes. It's hard to imagine a case where this difference matters.
Knowing stuff is what we're paid for, otherwise we'd all be making minimum wage. Besides, there are plenty of non-bash shell scripting resources out there, which is good to learn if you want to work with the BSDs or proprietary UNIX systems.
Powershell on UNIX is like Perl on Windows. It works, but it's weird and alien. But the same can be said for .NET, really.
It's already difficult enough to make a successful book adaptation, even WITH authorial intent. Can't imagine that hours of patchwork AI-generated video, with all its artifacting and consistency errors, will fare any better than "The Rings of Power".
I can see it using some form of PEFT so that the output becomes consistent with both the setting and the characters and then it is about generating over and over each short segment until you are happy with the outcome. Then you stitch them together and if you don't like some part you can always try to re-generate them, change the prompt, ...
I don't believe we will live to see the day where these models can replace a competent production team. At best they'll be what LLMs are to creative writing, which has so far only conclusively replaced low effort blogspam and fraud/plagiarism.
From a quick search, Ubuntu LTS releases are supported for 5 years as a baseline, and Ubuntu Pro goes up to 12 years. RHEL releases are supported for 10 years.
I'm guessing it's similar with SUSE and other "business" distros.
Ubuntu Pro and RHEL are both 10 years for their standard lifecycle, with optional add-ons to go longer. Ubuntu's is called "Legacy Support" to get an extra 2 years, RHEL's is called "Extended Life-cycle Support" to get an extra 3-4 years.
Baffles me how this industry is basically speedrunning through the troubled history of regular finance, and every piece of legislation and every institution has to be rebuilt from scratch even though the mechanisms and the problems are almost exactly the same.
I always found the idea of a free, unregulated financial market being a positive thing amusing. Many of these regulations were made because more or less complex loopholes got exploited and many less wealthy people lost their money. And quite a few of these people with practical experience in these various exploits are still around.
Not sure if people who opted out of security expected to be doused in gasoline. There is something to say about whether this state of no security is generally desirable by society. Everywhere else this happened was eventually regulated.
So thinking crypto will be an outlier is wishful thinking since it will never be allowed to be more powerful than governments. At most, new world orders will be created, but they will settle and be like the old ones, with some new more crypto native rules. They will always know who you ar and who you’re transacting with and where either of you are.
Current crypto fanatics are assuming they will all be part of this club. This road will be filled with poor old men with fewer fingers and lots of regret.
I want crypto to succeed, but I don’t expect it will be unregulated. You’ll pay the same taxes, you’ll go to jail if you try to avoid them or if you send crypto to entities banned by governments. Eventually the things that make crypto so valuable will be hammered out so it’s more like fiat.
Maybe the value will crash or wealthy people of today will find a way to freeze it into reserve currencies (like the newly minted federal crypto reserve), but after some point it will stop being a source of wealth just by holding it at the right time. You will need to exchange it with value you create.
The math of crypto wealth by HODLing is unsustainable.
I've always liked this analogy because it accidentally implies something I believe to be true - the crypto industry will eventually overtake transitional finance while moving at great speed. It says a lot about how bad the traditional finance industry is that this is the easiest path forward that the market found.
> I've always liked this analogy because it accidentally implies something I believe to be true - the crypto industry will eventually overtake transitional finance while moving at great speed.
It isn't implying that. It is implying that it will end up at the same place as the traditional finance.
> It says a lot about how bad the traditional finance
What is so bad about traditional finance that crypto fixes?
"Bad money drives out good" because when they have both, people will prefer paying (getting rid of) the bad while keeping the good for themselves. That has nothing to do with what's happening with cryptocurrency.
