pleroma.debian.social

pleroma.debian.social

Wouter Verhelst | @wouter@pleroma.debian.social

Debian Developer. husband. ex-FOSDEM organizer. Tennis lover. Amateur musician.

If it ain't fun, you're not doing it right.

@foone
Ok, ok, I lie. These days there's 'emile', which is able to boot Linux without Mac OS on some m68k models. But not then. And I don't think Emile ever supported the Q950.

@foone
Eventually I decide it's not going to work, give up and load Linux again (the machine was an official Debian build host for the m68k port).

Mid boot it just started making this... noise. As if there's an air plane lifting off. I panic, check the console... and discover that Linux found the disk and sent it the spin up command.

Reboot, open the partitioning tool, everything works. ๐Ÿคฆ

@foone
It turned out that these specific AS/400 drives needed to be spun up before they could be used, they don't do that on power up.

So here I go, trying to upgrade a Mac Quadra 950 with a 2G(!๐Ÿ˜ฑ) hard drive, but nothing happens. I'm thinking maybe I did something wrong? But after searching for hours, replacing the cable, and fiddling with various things it just never shows up in Mac OS. And in order to use it under Linux, you need to partition it under Mac OS.

@foone
That reminds me of my experience with installing a hard disk from an old AS/400 into an m68k Mac.

Fun fact: Mac OS classic does not support drives that need to be spun up.

Linux does. But booting Linux on an m68k Mac requires that you boot Mac OS first, then run the 'penguin' program, which loads the Linux kernel and boots that (not very secure, this Mac OS thing).

Me, years ago:

I'm going to buy a bean-to-cup machine! So much easier? And no pods, for the environment!

Me, these days:
Oh the drip tray is full. *Empties drip tray*
Oh the used coffee compartment is also full. *Empties that*
*Powers on machine*
Oh the water compartment is empty. *Adds water* *starts coffee cycle*
Oh that grinder doesn't sound right. *Cancels coffee cycle* *adds beans*

There are times where I yearn back for the predictability of a French press.

@ajroach42
Today. And it's not even 9 am yet ๐Ÿ™‚

@mirabilos
Charles is the author in the same way that Linus is the author of Linux: he kickstarted it and wrote the initial batch of code, but he hasn't touched it in years, and most of the current code is yours.

You're the author.
@navi @dalias

@b0rk
In other words, almost half the standard is about standards for upstream, rather than for the packaging-specific bits.

That comparison is a bit skewed though, because a lot of the last part of the document includes other standards, such as FHS or XDG, by reference.
@bookwar

@b0rk
To demonstrate how far this goes: Debian's policy document (https://www.debian.org/doc/debian-policy) explains the technical requirements of a Debian package. The first 5 chapters explain the technical details of the packaging system; the next 2 explain how the packaging-specific bits should act. The 5 remaining chapters explain how the packaged software should behave.
@bookwar

@b0rk
These improvements are usually pushed back upstream, because distributions don't want to have to maintain things like that in a branch long term. But these are shared interests, and for those, distributions are the ideal point to implement them.
@bookwar

@b0rk
That's one example.

In general, distributions are points where standardisation between various bits of the Linux ecosystem actually matters.

For instance, you can rely on your system following the FHS, not because upstream developers care, but because distributions do. Reproducible builds are another example of things that were pushed by distributions.
@bookwar

@drsimevans
If we keep doing this, it will eventually make the power plant companies go out of business!! Scandalous!!!1eleven!

@bayindirh
As a side effect though, there is a vim and most of the tools that I use for development packaged for termux, so my development on my Android tablet is the same as the one on my laptop.

Eclipse can't do that.
@foone

@bayindirh
Anyway, my point being, I used to like using an IDE about 20 years ago, but I stopped seeing the benefits and have in fact improved my productivity by not having an editor with so many knobs and options that I forget I'm actually here to code. When I have to, I go sad, mostly because it takes so long to boot...
@foone

@bayindirh
For custom data file types, I either use vim add-ons to help editing (e.g., for YAML) or switch to a different application altogether (e.g., a spreadsheet for CSV data).

Project portability is indeed the one thing that doesn't work very well with autotools if you need windows support, but I rarely do, so it doesn't matter to me; and if I do, I could teach myself how cmake works and deal with it.
@foone

@bayindirh
For remote deployment/debugging, I keep an SSH session open to a node with an NFS mount of my development tree, and use gdbserver to debug over the network while using an editor-integrated debugger, ddd, or something more basic like gdb -tui (which gives you a curses-based UI that is quite useful)
@foone

@bayindirh
The main point of difference though is that I consider my OS to be the development environment, rather than any one app. Once you switch to that mindset, you realise that you don't need to have everything integrated, and it can actually speed things up IME.
@foone

@bayindirh
I rarely write makefiles by hand anymore, except for very small projects. I personally prefer autotools. While that's certainly not for everyone, it does come with build profile possibilities built-in. Alternatives such as cmake do too.

Configuration snapshots etc is just git.
@foone

@bayindirh
I'm not a fan of 'bespoke' anything, as it implies a smaller development base as opposed to something more generic.

I can call the GCC or clang static analysers on code and display results in vim though. Same with valgrind.
@foone

ยป