radonek

https://en.wikipedia.org/wiki/The_History_of_the_Decline_and...

Small phones do exist. I'm quite happy with my Unihertz Jelly.

Umm, if I read it correctly, your barman pours Guinness into 100MB glass and empties rest of the bottle into drain. I'd rather drink straight from the bottle. Like, you know, the cat does it.

Just look at the project site (which at this point is a README on github). I see a few lines about upgrade issues, absolutely nothing about project itself. What improvements or changes over Xorg are implemented? Roadmap of future changes? Why should I pick this over Xorg?

Instead, we get pageful of whining about how bad bad big tech pissed on authors cornflakes. Hate? I don't see any reason to hate the guy. But I also don't see a single bit of reason to take him seriously.

Thanks for reference. This pretty much confirms what is written between lines on linked site.

ORM is not as much solution to a problem as it is way of doing things. Certain kind of programmers observe that SELECT is kinda like getter, UPDATE is like setter and so on… It looks like cool abstraction, relatively straightforward to implement and most people working with databases toy with their own ORM code, have fun and thinks themselves very clever. Think of it as a rite of passage if you will.

…until they try to do JOIN. Or subselect. Or CTE. Or just about any other powerful SQL feature. Materialized views, triggers, sharding, atomic operations, you name it. At which point ones who are actually clever realize this idea has some serious limitations and drop it. Not because it can't be done – there are some nifty and well working ORMS out there – but because its bound to end just as complicated as sql itself. So why bother?

IMO main reason for existence of the ORM libraries is because back in the day, true object databases failed to take off for various reasons.

Absolutely. I've hardly ever done bieliptic transfer in KSP, but I stick to bieliptic plane changes for almost every big inclination change. Δv savings can be huge.

Services should be designed either as providers, which herd data and do nothing on their own, and workers which actually do stuff but hold no data of their own. Think daemon with a REST api, siting on a database and cronjob implementing some business logic.

This pattern avoids transitive dependencies, especially "errors from faraway lands".

Executive summary: "Kernel devs refused to drop everything and immediately start rewriting their code in Rust, which means that linux is inevitably doomed."

This seriously reminds me of Java zealots in worst days of Java Everywhere circus.

I'd say find some screenshot of Windows 95 with multiple applications running and marvel at it. Google Workspace administration console is good example of UI in many ways less capable and useful then what I used twenty years ago. To name just a few:

- listviews are limited to 50 items. MSDOS apps running on 640kB memory could do better back in eighties.

- Adding a new item does not refresh listview. I had wits to do that when I was 13yo toying with qbasic.

- UI "windows" are just floating <div>s that can't be moved, with controls wherever UX monkey happened to have dropped them. Heck, even the (fake) close button can't have consistent left or right position. Compared to that mess, Windows 3 apps look like work of art.

- Many actions take long clock-to-display time. How come that rendering a few lines of text and some buttons is slower on gigahertz class multicore machine then pitiful 200Mhz celeron?

- Even the early, amateurish web apps from nineties, pushed through pathetic dialup internet had the common sense to check session timeout BEFORE displaying a form for user to fill in. Google today? Not so much.

I could continue, but this makes me sad.

I hate the way GUI apps are devolving back to nineties. Resizable windows, clipboard, theming, menus, keyboard shortcuts… stuff that made computers easier to use is disappearing. Apps nowadays are created by graphic designers who don't know what color contrast is and UX specialists who never heard word ergonomy, directed by people who consider wheel reinventionalism to be height of innovation.

That was fun. But I miss some.

105102414410138859640127147104

Once upon a time, I was tasked to rewrite build scripts for windows based team from .bat files to bash scripts (via a git-bash). People on that team were not exactly unix fans, in fact they resisted hard almost everything coming from us linux weirdos. But reduction in build time was so big they asked for this and embraced it with genuine love.

I, for one, see this as improvement, affixed cap is convenient most of the time. If it's not, its easy to tear it away.

IMO real problem with caps is that this was not invented by VC backed startup, which makes it ideological challenge to some people.

to quote about distro packages: "To be blunt, this dependency management system never should have been allowed. It caused no end of confusion for everyone…"

Yeah, package management that actually works must be terribly confusing to some people.

https://www.nasa.gov/history/history-publications-and-resour...

Learning C. Never written any serious code in it, but still among most usefull skills to have.

I have recently had unfortunate experience of being tasked to dockerize python project depending on ML "library" (namely, rembg). I hope to never, ever touch ML crowd crap again.

To trigger a rebuild, you first need to know relevant upstream updates. To recognize them, you need to know your dependencies. Docker provides no means to track dependencies. In fact, avoiding dependency knowledge is one of its major selling points.

I wont say it's impossible problem to tackle. But I doubt any solution you find could work better or be less complicated then regular packaging. Unlike docker, debhelper, rpm, ebuild and others were designed for this task, and have decades of experience in the field.

Just out of curiousity – what other languages do you know and use?

Rust language has pros and cons, like everything. Rust community sometimes exhibits this "everything needs to be rewritten in our favorite toy language, NOW" attitude that reminds me of worst times of Java hype.

Then again, every attempt at dethroning C++ came with it's own crowd of fanatic cultists, so maybe it's just that C++ is cursed.

Opera browser had this feature since dawn of time and some others copied it.

I'm not sure I understand this. Do you mean having an app instance using library code from local git instead of pip package? I do that all the time with a Makefile and some symlinks.

What a great article.

We start with learning that we absolutely need this Poetry thing because… it's what everyone else uses. It's refreshing to see author who can skip usual badly argued justifications and just plain admin that he does not know shit and is just following rest of the herd. Then we continue by "solving" depependencies by usual way of ignoring them and just freezing whatever happens to be present.

Then there is inevitable firing up of virtualenv, because that's just what you have to do when dealing with messed up dependencies.

Next one is new to me. Apparently, one does not just set up git hooks nowadays but use separate tool with declarative config. Because if you ever happen upon something not covered by the Tool, that would mean you are no longer part of the herd.

Then we push our stuff straight to pypi, because of course our stuff can't possibly have any dependencies outside of python herd ecosystem. It's not like we knew our dependencies anyway.

Then comes the fun part, pulling in tox, because when you have special tool to handle dependencies, what you just need is another tool with different environment and dependency model.

Code quality section I will just skip over, seeing what pass for code quality these days makes me too sad. What follows is setup of several proprietary projects that modern opensource seemingly can't exist without. What is more interresting is "tyding up" by moving code from git root to subdir. Now, this is of course perfectly sensible thing to, but I wonder why is it called 'src'? Maybe some herd memeber saw compiled language somewhere and picked it up without understanding difference between compiled binary and source code?

Now don't take this as if I have problem with the article content in itself. No, as a primer to modern python packaging it's great. It's not authors fault that his work is so comprehensive it lays out bare all the idiosyncrasies, herd mentality, cargocultism and general laziness of python ecosystem these days. Or is it?

You are going from one extreme to other and in my experience this will end up messy, unless interface in question really allows for all possible parameter combos. I'd rather ask which params are required and give a serious thought to setting up sensible defaults for the rest, so that you can end with something like this:

   resizeImage(imagePath, 300, 200, {crop: true})

Unihertz Jelly. Look it up. You can install all the social media crap you want, but there is not much doomscrolling to be had on that tiny 3" screen. Same thing with internet - browser is there, but I only ever used it in dire circumstances. There are downsides (maps are not exactly great experience) but also upsides. Not least of which is poking fun at iphone owners about having 2.5mm audio jack in this tiny thing that their huge brick apparently is too small to fit :-)