dima55

Are they though? The "complex .d-file generation" is "gcc -MMD" and a "-include *.d" at the end of the Makefile. You specify the dependencies, and it's on you to get those right, as it is in every other build system. I've never seen a race condition.

The problem with Make, is that it works just well-enough to allow people to sorta get it to work without requiring them to learn how to actually use the thing. Then they don't read the manual, and complain that Make doesn't, in fact, work.

You want emacs and https://github.com/caldwell/commit-patch. Like 'git add -p' but much faster and more powerful.

The #1 thing anybody should be asking for here is a list of newspapers they archive. I cannot see it. The obvious competitor to these people is https://www.newspapers.com and they at least have a crude one: https://www.newspapers.com/papers. Note that the Seattle Times (and newspapers from the NW in general) are missing. Does oldnews do better here?

A minor note about things like keep-lines: you can do the same thing, with more power by invoking the shell: (keep-lines "abc") is equivalent (or at least mostly so) to

  C-u M-| grep abc

Clearly you can replace the grep with whatever. I do this all the time, so I have C-u M-| remapped to C-M-|.

As a student, you'd be well-served to explore the various power tools people have used for many decades, with emacs being at the top of that list.

Thanks for the post. The obvious comparison is feedgnuplot: https://github.com/dkogan/feedgnuplot/

That works similarly in that it plots standard input. The backend is gnuplot, which is a double-edged sword: it's far more full-featured than brplot, but almost certainly is much slower also. I'll try out brplot to see if it would be a good replacement for cases where speed is important. Thanks!

Yep. There's a reason for the way I did it, but clearly I need to change it. Thanks for looking.

The docs link to the "guide" right at the top. This has basic usage examples and images: https://github.com/dkogan/gnuplotlib/blob/master/guide/guide...

Lots of people have been using these systems on their desktops for decades. This meme really needs to die.

Why wouldn't you just use stock Debian? The first rpi used a weird CPU, which didn't map well to the CPUs supported by the stock OSs, but that hasn't been true since that very first one.

You can get quite far by piping to other tools and/or using DSLs. pivoting can almost certainly be done by the luau support in qsv (or `vnl-filter`, for instance). Summing and grouping is something that `datamash` does well (or qsv luau probably, or `vnl-filter --eval`). Adding a column once again can be done with luau or `vnl-filter`.

Would you be more likely to use this tool if it had even more stuff in it requiring reading even more documentation? That's a genuine question.

In addition to being annoying, it raises questions about whether it is free software or not. Some people care a whole lot about that. And some people have higher standards about being nagged. And lots and lots of time was spent discussing solutions, for instance: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915541

For simple analyses (i.e. what most people do most of the time) doing this on the commandline gets you there faster. I use vnlog (https://github.com/dkogan/vnlog/). By the time you fired up your editor to write your Python code, I already have analyses and plots ready.

An incomplete list of other similar tools: https://github.com/dkogan/vnlog/#description

Aren't there a million of these? I used rosegarden something like 20 years ago. Still looks like it's around, and looks far nicer than it was! Go `apt install rosegarden`

Alternative very appropriate for some uses cases: `vnl-join` from the vnlog toolkit (https://github.com/dkogan/vnlog). Uses the `join` tool from coreutils (works well, has been around forever), and `vnlog` for nice column labelling

Make is a language for making build systems. CMake is a build system that uses Make written by people who haven't read the manual. Anybody touching build systems at all needs to do themselves a huge favor: read the GNU Make manual to be able to write a Makefile to support a small project. This isn't difficult, and gives you wonderful perspective about what build systems are great and which aren't. CMake is good if you need to support many different unixes and xcode and visual studio. If you don't, then cmake gives you lots of pain for no benefit.

Make is simple and good-enough for most cases. I use this: https://github.com/dkogan/mrbuild

But it's not special and there are lots like it. And they are all infinitely better than cmake

Yes. Thank you. Make is a victim of its own success in many ways.

Because Make is perfect for 99% of cases. And adding the extra 1% of features would be a mountain of extra work and complexity. Bazel does that, but I don't work on anything that needs its complexity, so for me and most other projects it wouldn't be a step forward.

Make is great. Even has a debugger: https://remake.readthedocs.io/en/latest/debugger.html

Sorta. He has a license (MIT), but no copyright statement. The license is an agreement between the copyright holder and the user. Normally he would have gotten the sign-off from his employer to release this, and this thing would be Copyright: Box, License: MIT. But there's no explicit copyright holder stated, which makes me think that he just uploaded and "licensed" code that he doesn't own.

Or the vnlog tools can do this. There are many ways to do data processing on the commandline now.

I've used sid on my machines for decades, as have many other people. Works great. It's not an official "release" in that it's not all tested together, but neither is Arch, really.

The second one is more work and it's what you want. Because it gets stuff into the main archive that everybody benefits from in the future. Otherwise your project is a series of hacks that create an unmaintainable mess.

Good lord. I'll never understand why people promote this project, since it's main feature is that he's doing it wrong. The complexity he's trying to avoid exists for a reason, not because people like complexity.

OP: post here: https://lists.debian.org/debian-jobs/

What did you do with that string, exactly?

"rebootstrap" is the tool used today to bring up a new architecture. My understanding is that most of the process is now automated.

Debian is a mainstream OS used by millions, while yocto is niche. Package availability isn't comparable, and you don't have to look hard to find missing things.

And yes. I can install a cross-compiler (from the stock repo!) and custom-build whatever (not 100% of the archive is cross-buildable yet, but most of it is). And most of the time you don't care about the details, and you don't need to cross-build anything: the full Debian archive is pre-built and available on all the supported architectures (whatever you care about is probably on that list).

And there's another big advantage. Developers might be using a different-architecture machine for their testing, and it's really nice to have an identical set of installed packages and version across dev and deployment boxes, even if they have different architectures. This is actually a very common case: people develop on their amd64 laptops, but the deployment might happen on an arm, or something.

You can custom-build Debian packages in the same way. Rarely does anyone actually do it because it rarely actually matters.

Yocto has no place on any machine that isn't heavily resource constrained. A "normal" OS like Debian gives you multitudes of advantages at the cost of a little extra disk space: thousands of packages available with one command, tons of available tools, support for many different architectures, cross-building. AND you can do both at the same time. At $JOB we have hardware with a vendor-provided yocto thing that has some binary hardware drivers. So we can't dump yocto completely. Instead we have Debian running in a chroot, talking to the binary driver running in native yocto via a pipe. Recommended!

If you do this sort of thing more than once ever, look at the feedgnuplot tool (http://github.com/dkogan/feedgnuplot). It'll make your life easier