this post was submitted on 07 Feb 2024
162 points (98.8% liked)

Open Source

31200 readers
267 users here now

All about open source! Feel free to ask questions, and share news, and interesting stuff!

Useful Links

Rules

Related Communities

Community icon from opensource.org, but we are not affiliated with them.

founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] TCB13@lemmy.world 38 points 9 months ago (3 children)

He makes a few good points, developers are becoming hostages of those cloud platforms. We now have a generation of developers that doesn’t understand the basic of their tech stack, about networking, about DNS, about how to deploy a simple thing into a server that doesn’t use some Docker BS or isn’t a 3rd party cloud xyz deploy-from-github service.

Companies such as Microsoft and GitHub are all about re-creating and reconfiguring the way people develop software so everyone will be hostage of their platforms. We see this in everything now Docker/DockerHub/Kubernetes and GitHub actions were the first sign of this cancer.

Before anyone comments that Docker isn't totally proprietary and there's Podman consider the following: It doesn’t really matter if there are truly open-source and open ecosystems of containerization technologies. In the end people/companies will pick the proprietary / closed option just because “it’s easier to use” or some other specific thing that will be good on the short term and very bad on the long term.

The latest endeavor in making everyone’s hostage is the new Linux immutable distribution trend. Immutable distros are all about making thing that were easy into complex, “locked down”, “inflexible”, bullshit to justify jobs and payed tech stacks and a soon to be released property solution. We had Ansible, containers, ZFS and BTRFS that provided all the required immutability needed already but someone decided that is is time to transform proven development techniques in the hopes of eventually selling some orchestration and/or other proprietary repository / platform / Docker / Kubernetes does.

“Oh but there are truly open-source immutable distros” … true, but again this hype is much like Docker and it will invariably and inevitably lead people down a path that will then require some proprietary solution or dependency somewhere (DockerHub) that is only required because the “new” technology itself alone doesn’t deliver as others did in the past. Those people now popularizing immutable distributions clearly haven’t had any experience with it before the current hype. Let me tell you something, immutable systems aren’t a new thing we already had it with MIPS devices (mostly routers and IOTs) and people have been moving to ARM and mutable solutions because it’s better, easier and more reliable.

The RedHat/CentOS fiasco was another great example of this ecosystems and once again all those people who got burned instead of moving to a true open-source distribution like Debian decided to pick Ubuntu - it's just a matter of time until Canonical decides to do some move.

Nowadays, without Internet and the ecosystems people can’t even do shit anymore. Have a look at the current state of things when it comes to embedded development, in the past people were able to program Arduino boards offline and today everyone moved to ESP devices and depends on the PlatformIO + VSCode ecosystem to code and deploy to the devices.

Speaking about VSCode it is also open-source until you realize that 1) the language plugins that you require can only compiled and run in official builds of VSCode and 2) Microsoft took over a lot of the popular 3rd party language plugins, repackage them with a different license... making it so if you try to create a fork of VSCode you can’t have any support for any programming language because it won’t be an official VSCode build. MS be like :).

All those things that make development very easy and lowered the bar for newcomers have the dark side of being designed to reconfigure and envelope the way development gets done so someone can profit from it. That is sad and above all set dangerous precedents and creates generations of engineers and developers that don’t have truly open tools like we did.

The “experts” who work in consulting companies are part of this as they usually don’t even know how to do things without the property solutions. Let me give you an example, once I had to work with E&Y, one of those big consulting companies, and I realized some awkward things while having conversations with both low level employees and partners / middle management, they weren’t aware that there are alternatives most of the time. A manager of a digital transformation and cloud solutions team that started his career E&Y, wasn’t aware that there was open-source alternatives to Google Workplace and Microsoft 365 for e-mail. I probed a TON around that and the guy, a software engineer with an university degree, didn’t even know that was Postfix was and the history of email.

[–] Septimaeus@infosec.pub 12 points 9 months ago* (last edited 9 months ago) (1 children)

In the end people/companies will pick the proprietary / closed option just because “it’s easier to use” or some other specific thing that will be good on the short term and very bad on the long term.

I agree with most of the above, just wanted to relay an explanation given to me years ago by my then eng director in an argument about this. He said the reasons we tend to use proprietary / closed platforms and deps in business settings is not necessarily because the software was better or easier to work with. Clearly it often isn’t.

It’s because of (1) built-in factoring and infrastructure, (2) built-in domain expertise that would otherwise require hiring or training, and (3) contractual guarantees that can be invoked when things go wrong. All of which attenuate risk and make development timelines and outcomes more predictable.

His line was “OSS is free like a puppy is free.” That is, most businesses aren’t old enough to handle the responsibility, and that’s why we still sometimes use shitty proprietary software.

[–] TCB13@lemmy.world 5 points 9 months ago* (last edited 9 months ago) (2 children)

It’s because of (1) built-in factoring and infrastructure, (2) built-in domain expertise that would otherwise require hiring or training, and (3) contractual guarantees that can be invoked when things go wrong. All of which attenuate risk and make development timelines and outcomes more predictable.

Yes, I believe I also said that in some other point. I've been there and totally agree with him.

most businesses aren’t old enough to handle the responsibility, and that’s why we still sometimes use shitty proprietary software.

Once they become "old enough" nobody wants to personally be responsible for anything and politics and corruption get involved and you keep buying proprietary shit.

[–] hitmyspot@aussie.zone 2 points 9 months ago

Also, once they are old enough, change is harder. It's why all the software these days is freemium. Small companies use it as its free. Medium companies pay for it as it's easier than using something else.

[–] Tangent5280@lemmy.world 1 points 9 months ago

How do we break out of this path of trying to get big enough to break custom, and once you're big enough not having the guts to test wide sweeping changes?

[–] Freesoftwareenjoyer@lemmy.world 6 points 9 months ago (1 children)

Speaking about VSCode it is also open-source until you realize that 1) the language plugins that you require can only compiled and run in official builds of VSCode and 2) Microsoft took over a lot of the popular 3rd party language plugins, repackage them with a different license… making it so if you try to create a fork of VSCode you can’t have any support for any programming language because it won’t be an official VSCode build. MS be like :).

I'm opposed to having repositories for plugins. I don't want my code editor to connect to the internet at all. If I need some popular plugin, it should already be available in the repository of the distro that I'm using. Some distributions of VIM and Emacs download a bunch of plugins on launch from who knows where. I don't get why people are fine with that.

It's similar with Flatpak and Snap. Oh and each programming language has its own package manager too, of course (NPM belongs to Microsoft too, btw). Everyone and everything wants its own package manager or a separate distribution system.

For now I use VSCodium in firejail to prevent it from accessing the network and I don't install new plugins. I haven't heard of any better editor, unfortunately.

[–] TCB13@lemmy.world 3 points 9 months ago* (last edited 9 months ago) (1 children)

I suggest you have a read at https://ghuntley.com/fracture/

What you're doing is a solution but it doesn't mean it is legal nor should anyone go through that pain. Microsoft completely subverted the spirit of open-source with VSCode.

I’m opposed to having repositories for plugins. I don’t want my code editor to connect to the internet at all.

I'm not much against having repositories with plugins, extensions or whatever BUT they should be like Debian, you can just pack everything into images / a folder and use offline for ever when required. This is one of my big criticisms over Flatpak you can't simply have a working and fully offline archive of the thing that will survive forever without Internet. Same goes for modern Docker powered solutions and JavaScript frameworks.

I'm "really opposed" to having to rely o Internet connections to setup and do anything, things should be done in a way that you can have it all offline from setup to daily tasks.

[–] Freesoftwareenjoyer@lemmy.world 1 points 9 months ago

I've read it, but I don't really understand the legal issue. I'm also not sure what could be illegal about VSCodium. It uses the Open VSX store for downloading extensions (but not every extension is on there).

It would certainly be better if VSCode was under a Copyleft license, so that it couldn't be turned into proprietary software and maybe that way addons would also have to be Free Software, like in Blender. But Microsoft clearly doesn't want that.

I’m not much against having repositories with plugins, extensions or whatever BUT they should be like Debian, you can just pack everything into images / a folder and use offline for ever when required.

Yeah, that's a good idea. They could also just be added to Debian, which would solve this problem, but there also would be another benefit for me. Most people don't care about that, but I want to only use Free Software. When I install something from Debian's free repository, I don't have to worry that it might be proprietary, because they only allow Free Software there. I don't have this certainty when installing software from most other places.

Same goes for modern Docker powered solutions and JavaScript frameworks.

Some JavaScript frameworks and libraries seem to be packaged in Debian. But most people use NPM, of course.

[–] Tangent5280@lemmy.world 3 points 9 months ago (1 children)

Bravo for the great summary and expanding on the article. I'd like to subscribe to everything you write.

Agree on the VScode comments. Some of the scummiest business maneuvering from Microsoft. The terrifying part is its slowly becoming so ingrained that its going to take a long time and a lot of directed effort to undo the damage.

Agree on the consultancy angle - this is woefully becoming more and more commonplace as true from-scratch engineering dies on the wayside. Do you think this can be mitigated by, say, college courses that concentrate on the base form of the programming domain? Maybe web development with backend hosted on a machine in the classroom, with a registered domain on an external registrar instead of the usual localhost bullshit, and students responsible for routing etc? Like an emulation of the old days when you started learning web dev on your home computer and stayed with it until you were pretty much a journeyman engineer?

[–] TCB13@lemmy.world 2 points 9 months ago

Bravo for the great summary and expanding on the article. I’d like to subscribe to everything you write.

Well at least I'm not getting bashed by shitting on cloud hypes, Docker, immutable distros this time :P

Agree on the consultancy angle - this is woefully becoming more and more commonplace as true from-scratch engineering dies on the wayside. Do you think this can be mitigated by, say, college courses that concentrate on the base form of the programming domain? (...) like an emulation of the old days when you started learning web dev on your home computer and stayed with it until you were pretty much a journeyman engineer?

What you're proposing would be interesting yes, but I don't believe it would work out. Most student don't have the drive that we had in "old days when you started learning web dev on your home computer"... they just want to pass a few courses and graduate. I believe you know as well as I do that what you're describing required a LOT of dedication and sleepless nights and nowadays society as a whole is focused on instant gain, quick receipts (udemy courses) and 10s short videos.

IT is just suffering from the same issue, the solutions that are delivered nowadays are all just about ROI and instant delivery no matter the cost that they will have in the future. This was kind of the aftermath of SCRUM/Agile and the need to suddenly create complex software for everything just because developers are cheap and we've more CPU power available than we really need.

To be fair those development methodologies were, most likely, created so companies could onboard young and inexperienced developers very fast and get them to ship features quickly. No other field works the way IT works, people take their time to learn their craft, there are legal requirements sometimes and nobody expects you to create a Facebook clone in a week for 500 €.

All those new technologies keep pushing this "develop and deploy" quickly and commoditizing development - it's a negative feedback loop that never ends. Yes I say commoditizing development because if you look at it those techs only make it easier for the entry level developer and companies instead of hiring developers for their knowledge and ability to develop they're just hiring "cheap monkeys" that are able to configure those technologies and cloud platforms to deliver something. At the end of the they the business of those cloud companies is transforming developer knowledge into products/services that companies can buy with a click.