• 3 Posts
  • 62 Comments
Joined 1 year ago
cake
Cake day: July 23rd, 2023

help-circle

  • Do you think I’ll like i3?

    No idea. I only have (a little) experience with i3.

    Wnat I do know is that they’ll all require you to configure them, and it’s always a huge PITA to configure a OS or parts thereof, whichever it may be. But I figure even if I spend 2 days doing that, it’s a one-off job, and then I can reuse my favorite config forever. So it’s work worth doing.

    you’re OK with so called bloat anyway

    I don’t mind bloat if it’s worth it. Cinnamon / Gnome for instance is a bit of a pig (less than KDE / Qt for sure, but still) but I like it so… Okay. Conversely, I’ve yet to encounter any Electron app that offers anywhere near the amount of features that would justify the hundreds of megabytes and the amount of CPU Electron requires. Or Snap, Flatpak or Appimage packages for that matter. Those are wasteful for the benefit of the developer, not for yours.



  • That’s what I thought too - and I tried other tiling window managers in the past, only to quickly return to whatever I was used to. But somehow i3 hit the spot, It you’re used to screen or tmux, this thing has the same DNA and you’ll feel right at home. Give it an honest try, you might just like it.

    But I do believe that you kind of have to be halfway there already to “get it”. My halfway-there was being so used to the same concept in the terminal. If you’re never exposed to tiling in any way, shape or form, maybe it’s more of a stretch.



  • what i don’t like about most tiling WMs is they are keyboard only. you can’t hold a beverage in one hand and use them easily with the mouse.

    Depends. Here for example, I’m lounging in the couch with a beer in one hand, watching Youtube videos in FreeTube, chatting with a friend in Signal and lazily browsing a few browser tabs and windows the rest of the time. The browser windows are arranged in one tabbed workspace, Signal in another workspace and Freetube in a third workspace, all of which are available with a mouse click. I’m basically not touching the keyboard unless I have to.

    I guess it depends on how involved you want things to be with one hand clutching a beer 🙂 Me, that’s as complicated as I’m willing to let things get when I booze.










  • When I was a CS student in the early-mid 90s, my college had Unix only and we had to fight to get a free terminal to complete our assignments.I had a good 486DX with Windows 3.11 and I had heard of Minix, so I could do my assignments in the comfort (?) of my dorm room.

    I went to my local technical library to see if they had a box (that sort of places used to carry boxed OSes and specialized software back then). They didn’t, but they had this CD with Slackware written on it and the store owner said it was better. So I bought it on a whim.

    After many hours and a lot of recompiling the kernel and libraries right and left, the thing finally booted and ran surprisingly stable. My roommate saw it and immediately installed it on his machine. The next days we went buy a couple of 10base2 NICs, some coax and a pair of terminator, and before you know it, we had NFS going.

    It was our own Unix network and it was way better than college’s :) I never looked back.

    I did work with DRDOS as a kernel dev a few years later, which involved reverse-engineering bits of MSDOS 7 (yes, that’s the version of MSDOS Windows 95 ran on top of). That’s as close to working professionally with MS stuff as I ever got. Other than than, I’m a pure product of the Linux generation baby!





  • Well that’s one solution.

    We wouldn’t do this because we have a policy of modifying as little as humanly possible on the target system, because of the nature of some of our customers: we may not have the right to modify stuff right and left willy-nilly on those customer’s systems, and if we do, we have to justify why with a lot of paperwork. So we don’t: we install our stuff in one very formal, very stable spot of the hard disk (on Windows, c:\Users<username>), install missing modules, stick an icon on the desktop and that’s it.

    Historically, we also propose to install Python on the system if it’s missing (used to do that system-wide) and advise our customers to install it system-wide too if they did it themselves so we wouldn’t have to modify our installer (again, if we do, we have to justify the change when the customer is under configuration control, so we try to avoid change). Not anymore obviously.

    So yeah, we wouldn’t install Miniconda just for the purpose of not changing our installers. At this point, that’s enough change that I can just rewrite the installers: either way, I’ll have to communicate the change to the customers, so I might as well do it right.

    But my point was, if Python gracefully handled backward compatibility - as in, for example, you put in the shebang or near the shebang that you want the interpreter and pip to behave like, say, Python 3.10, and Python4.56 behaves like 3.10 did years later - then this is unnecessary work that I wouldn’t have to do.

    I had to rewrite our installers and other things to deal with Python 3.12’s new forcibly-enforced kosher way ot doing things because it won’t do thing any other way and compatibility be damned. That’s my beef with Python: after all this time, it’s still unstable and prone to breaking existing codebases.

    It’s a real problem for us and it has been for a long time: code that’s out there and working is liable to quit working when the Python interpreter changes. I have no idea how a 33-year-old language, ultra-widely used language such as Python is allowed to change regularly with little regard to backward compatibility like it was an early beta weekend project. This is truly unprofessional and it completely boggles my mind.




  • The problem is, our code has to run on a customer install regardless of the install. Typically they downloaded Python and installed it themselves on their machine, and more often than not, they have stuff running on their machines and modules installed for their own stuff, and I can’t go about telling them to install some other version and/or force them to use a certain tool to do so: it’s gonna break their own config and it’s going to piss them off.

    Our code has to run clean without fuss on Linux and Windows, regardless of what’s installed and how. All we require is any Python version between 3.6 and (now…) 3.12. We tell them they can use another version if they want but then they’re on their own if there are problems. We guarantee proper operation between 3.6 and 3.12. I just had to make sure our installers worked properly and performed a venv install when appropriate (almost required with 3.12 now) and our code ran without warning and without throwing a wobbler because of missing stuff that was there before 3.12 because I don’t want to tell people to spend extra efforts to downgrade and/or mess up their install on Win11.