A web browser that has all the shit the big tech companies added to make it hard to create a good web browser would be a good start. A web browser does not need webgl or wasm. I want to log into my bank to see how much money I have.
I work for a solar CAD+CRUD app that runs in browser. WebGL is more than fun stuff. Wasm is becoming The Way to run applications in a portable way in servers.
I want to log into my bank to see how much money I have.
The most infuriating part is that this is perfectly doable with 90s web technology. Even encryption was already available in the form of SSL, and that's arguably the only thing which has improved since then. The majority of technological "progress" has merely been the reinvention of existing technology in more inefficient ways.
I was too young to have a bank account back then. However, I can personally attest that the Toronto Public Library, around year 2000+/-2, had a Java applet on their public website which the general public used to search the library's catalog. I may or may not have saved a snapshot of one of those JAR files. Needless to say, the Java applet was awkward compared to a properly designed web application - e.g. loading screens, weird widgets that were neither web nor Windows, inability to select text by default, inability to use the web browser's UI controls (e.g. back/forward/reload/URL-bar).
There is no system of digital content distribution that can withstand the will of Government. The only thing that can be done is for the citizens of that government to wake up and take the power away from those that are wielding it to further enrich themselves at the expense of everyone else. I am not a user of TikTok but this is not a good development for our "perfect union", nor the freedom of the internet in the United States of America.
All these plan9 scientists love their own brand. I started using Go in 2012, but after they killed deps.dev I gave it up. Some years later when I wanted to get work done at work I tried to introduce it on my team and another engineer spent a good amount of time looking into the language and listed all the reasons why it sucked, and he was right. The main takeaway was, yeah it's simple, but it does silly things that makes it a pain to use (error handling and unused imports) to name a few. I personally like the error handling but hated the type system.
If you use goimports (which also runs gofmt) after commenting out code, you just have to save your file and it will remove any unused imports. There is no reason to go to the extreme extent of compiling your own modified version of go just for this. The tooling is already there.
The OP mentions that the reimport is the problem (in response to your tooling suggestion). If you comment out code while testing the imports are auto-removed. When you uncomment you need add the correct imports again.
I might not have used `goimports` before. I read now that it also auto-imports when you uncomment. That's neat, but it could auto-import the wrong thing, and I'm not sure how it would handle conflicts. It still seems worse than just ignoring my unused imports. Unused imports should be more of a linting thing? If the compiler knows its unused, I don't see why it can't just ignore it.
Yes, it can import the wrong thing (or version) but it doesn't happen that often in my experience. If you use the libraries in other files it can go off of what is already in your go.mod file.
My favorite explanation for the well known “worse is better” observation about systems software is that it’s a downstream of the fact that worse is free.
There have been vastly superior systems to Unix but with commercial licenses.
Unix itself was a commercial system, licensed by AT&T to various other companies, that nearly fragmented itself to death before being resurrected by the free/open variants (*BSD, GNU, and Linux). See https://en.wikipedia.org/wiki/Unix_wars
Everything was commercial back then. My point is that mature free implementations of Unix (BSD, Linux) came before free implementations of any superior systems and so they won.
Interesting question. I'm always curious at these other operating systems.
I was a teen at the time, but in hindsight, in '96-97 'open source' from commercial vendors wasn't the norm, and Lucent finding income from openInferno would've been big change in business model.
Java was meant to be familiar to C/C++ programmers, of which there were a lot. I'm not sure how Limbo would compare in terms of learning / productivity. And would there have been a Windows native "Inferno/Limbo" IDE type thing. (If there was one, please let me know)
Inferno would've needed a killer app. I assume it'd perform better than Java, and at the time it would've competed with small Java applets. Java desktop didn't happen, I recall Corel trying and failing to port Word Perfect to Java.
I don't know how if anybody ever tried to write an office suite in Limbo.
Inferno is based on plan 9 (shares kernel code)with a user space that fully runs in the VM. However, it can run on very small systems like microcontrollers and someone is currently actively exploring this: https://dboddie.gitlab.io/inferno-diary/index.html
Nomad will be there when managed k8s gets too expensive. I was looking at it seriously last year for on prem. I chickend put bcz I didn't want to be the only person on my team that understood it. We still don't have a solution, but nomad will be there for when we are ready to progress, regardless of the license.
Jenkins is rock solid. Been using it for three years to deliver highly critical software. The development experience is the worst of all ci tools since no one wants to setup jenkinspipelineunit to test the pipelines. Dagger might be the salvation here, but even that tool didn't support Jenkins out of the gate. And for those that are reading this, the statement about pipeline groovy being a trap is exactly right. Avoid writing groovy at all costs. No one on the team wants to get good groovy and if you do, you're weird. The way we do it is to just use the Jenkins file to call the scripts (or tools) with bare minimal script code.
Edit, forgot to add that I recently interviewed a bunch of candidates for a high paying job at a ai hardware company and every one of those candidates stated they worked on or near a project that involved moving from Jenkins to Gitlab CI.
> And for those that are reading this, the statement about pipeline groovy being a trap is exactly right. Avoid writing groovy at all costs.
I disagree with this pretty strongly. I've worked with Jenkins where it was all freestyle jobs and it was a nightmare to maintain. Pipelines written in groovy are essential to doing Jenkins well, imo. It's also not exactly hard to write groovy. It's basically Java, not some weird esoteric language nobody knows.
I'd suggest you wait until you spend a whole day on script approval and @NonCPS idiosyncrasies before you define Jenkins pipeline Groovy DSL as "basically Java". This doesn't mean you shouldn't be writing it, you should — but for the reasons completely different from its supposed "similarity to Java".
Oh ye keep it simple. I worked as a Jenkins admin for half a year and one day I woke up from a nightmare and realized that I've made some sort of parallelization batch job processor communicating via outputting bat-files, in Groovy, to cut down build times.
