Linux: vim isn't moe

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > Linux: vim isn't moe

Poopernickel: Oct 28, 2005; electricity bad; Fun Shoe

DoomTrainPhD posted:

You can create a post-build script to remove everything except libsystemd, or you could modify the package/systemd/systemd.mk file to do what you want.

I've updated systemd multiple times on the project I work on at work that also happens to use Buildroot + systemd and it's never broken in odd ways.

Edit* Also, Buildroot LTS versions have support for 2 years.

Solvable for sure. Also short-sighted in my crusty greybeard opinion.

Somebody wants to control systemd services, or do anything init related? Sure, depend on libsystemd. Go hog-wild. Don't pull it in for some stupid IPC bullshit. Not when there are a ton of portable/self-contained options. That's like adding a dependency on GNOME because you want to use the string parser.

I wound up packaging it by making a new libsystemd.mk in our br2-external that uses systemd.mk's steps but overrides the install step, and making that package conflict with Buildroot's systemd

Poopernickel fucked around with this message at 18:47 on Nov 1, 2021

# ? Nov 1, 2021 18:34

Adbot: ADBOT LOVES YOU

# ? Apr 16, 2024 13:49

hobbesmaster: Jan 28, 2008

sounds like a use case for a very specific yocto recipe!

# ? Nov 1, 2021 19:01

FlapYoJacks: Feb 12, 2009

hobbesmaster posted:

sounds like a use case for a very specific yocto recipe!

Or a package in an external tree in Buildroot. :shrug:

At the end of the day, your specific use case is very niche. The Buildroot developers and package maintainers (including myself) can't enable every option for every single niche. If you want, feel free to submit a patch to only build and install libsystemd.

FlapYoJacks fucked around with this message at 19:09 on Nov 1, 2021

# ? Nov 1, 2021 19:06

Poopernickel: Oct 28, 2005; electricity bad; Fun Shoe

what I want is for that developer to sack up and switch to a different IPC library

# ? Nov 1, 2021 19:12

FlapYoJacks: Feb 12, 2009

Poopernickel posted:

what I want is for that developer to sack up and switch to a different IPC library

Why? I assume they are using sdbus-cpp?

# ? Nov 1, 2021 19:18

Phobeste: Apr 9, 2006; never, like, count out Touchdown Tom, man

hobbesmaster posted:

sounds like a use case for a very specific yocto recipe!

yocto is the worst loving poo poo imaginable i hate it so much. intermixed shell and python, expectations to customize build environments, weird disagreements in names of things so you can't even grep, just dogshit. buildroot is also terrible. god drat it

# ? Nov 1, 2021 19:28

Poopernickel: Oct 28, 2005; electricity bad; Fun Shoe

DoomTrainPhD posted:

Why? I assume they are using sdbus-cpp?

Maybe, yeah. I'm not 100% sure.

# ? Nov 1, 2021 19:35

Poopernickel: Oct 28, 2005; electricity bad; Fun Shoe

Phobeste posted:

yocto is the worst loving poo poo imaginable i hate it so much. intermixed shell and python, expectations to customize build environments, weird disagreements in names of things so you can't even grep, just dogshit. buildroot is also terrible. god drat it

Yocto is good actually.

Buildroot is good too until you hit a certain level of design complexity.

# ? Nov 1, 2021 19:37

hobbesmaster: Jan 28, 2008

Phobeste posted:

yocto is the worst loving poo poo imaginable i hate it so much. intermixed shell and python, expectations to customize build environments, weird disagreements in names of things so you can't even grep, just dogshit. buildroot is also terrible. god drat it

that�s our Linux! laugh track

# ? Nov 1, 2021 19:46

FlapYoJacks: Feb 12, 2009

Poopernickel posted:

Yocto is good actually.

Buildroot is good too until you hit a certain level of design complexity.

And at what point does the design complexity get complex enough that Buildroot goes bad?

FlapYoJacks fucked around with this message at 20:14 on Nov 1, 2021

# ? Nov 1, 2021 20:09

BlankSystemDaemon: Mar 13, 2009

DoomTrainPhD posted:

And at what point does the design complexity get complex enough that Buildroot goes bad?

There is a theory which states that if ever anyone discovers exactly what the design complexity of Buildroot is for and why it is here, it will instantly go bad and be replaced by something even more bizarre and inexplicable.

There is another theory which states that this has already happened.

# ? Nov 1, 2021 20:17

FlapYoJacks: Feb 12, 2009

BlankSystemDaemon posted:

There is a theory which states that if ever anyone discovers exactly what the design complexity of Buildroot is for and why it is here, it will instantly go bad and be replaced by something even more bizarre and inexplicable.

There is another theory which states that this has already happened.

I maintain a fairly complex system that uses Buildroot. Indeed, maintaining multiple external trees is a pain in the rear end with Buildroot, and I ended up creating a container environment that parses some simple JSON files to setup, apply config fragments, and build defconfigs in an automated fashion. Is it a great solution? Meh, but it's better than manually setting up and building everything by hand. :shrug:

Yocto is incredibly clever in building multiple configs for boards all at the same time, I will give it that. Although the trade-offs of having to use recipes, and relying on tons of random recipes in different states of maintenance for various packages is just gross most of the time.

Edit* Feel free to roast me over this docker-init bullshit I cobbled together: https://github.com/aduskett/buildroot-docker-devel/tree/master/example-buildroot-project :v:

# ? Nov 1, 2021 20:23

BlankSystemDaemon: Mar 13, 2009

Mind you, BSD Makefiles contain conditionals, built-ins, more variable types, extensive modifiers, looping, and special attributes not found in other versions of make - but they're all documented in make(1).

BlankSystemDaemon fucked around with this message at 20:31 on Nov 1, 2021

# ? Nov 1, 2021 20:28

FlapYoJacks: Feb 12, 2009

To be fair, the python code:
- Is properly formatted with black
- Uses type-hints
- Passes mypy, pylint, and flake8 checks
- Has been poked at on and off for the better part of 5~ years or so.
- Is incredibly stable.

Sure, it could be better, but so far no complaints from several clients. :unsmith:

# ? Nov 1, 2021 20:32

Sapozhnik: Jan 2, 2005; Nap Ghost

Poopernickel posted:

edit: oh, and also the target config doesn't use systemd-init for ~*ReAsOnZ*~ , and Buildroot has no built-in ability to say "I want libsystemd without the rest of systemd" because that's dumb as hell

lol at the level of greybearding necessary to build an embedded system image and then going out of your way to banish the foul scourge of that unutterable teutonic blasphemer's most malevolent of perfidies, tormentor of services, blight upon reason and ravager of virtue, howl of darkest madness, accursed demon engine that eternally tortures all the souls of the damned

# ? Nov 1, 2021 20:50

Phobeste: Apr 9, 2006; never, like, count out Touchdown Tom, man

here's some bad stuff about buildroot:
- i hope you like make
- no you're gonna have to like it more than that. a lot more than that
- hope you like clean builds when you make any change other than "adding something to the build that was not previously being built"

here's some bad stuff about yocto:
- don't like make? that's fine, we don't really write make here. instead we write a dsl. the dsl looks like bash but you can also arbitrarily start writing a python function and call it directly from the bash. or write a python function and inject it as a task
- we're gonna use bash key value stores a lot just fyi
- oh ps even though we have some sort of weird key value store thing we're also going to do a lot of changing behavior and filtering via the name of a variable. for instance you can have MYVAR and also MYVAR:native and also MYVAR:target and MYVAR:target:imx and MYVAR:target:imx8mm and one will get selected based on some configuration
- we're gonna be doing a lot of shell style lists that are whitespace separated. we're gonna be doing a lot of overrides based on list ordering
- build configuration that selects everything, the equivalent of buildroot's defconfig, is in all the documentation supposed to be a thing you set up on your machine in a build directory. this is insane. so we're gonna be making some repos and automation that don't have a lot of good examples because everybody says "oh yeah just run this script then your machine's set up". gently caress you it's 2021
- we're gonna be doign a lot of submoduling because of this. lot of layer directories.
- oh ps we have layers. we're gonna need a lot of layers probably. all the layers are gonna get smooshed into a big global namespace (n.b. the namespace is "environment variables". yes this includes the entire text of recipes). all layers can override random things in each other arbitrarily. don't understand why something is/isn't building? well, have you tried ripgrep? trust me regular grep is not going to be good enough
- have any problem with any of the above? oh that's ok there's a bunch of random shell scripts you're never going to remember that you need to enter basically a chroot to use. these can do quite a lot of things because we actually track bidirectional metadata (e.g. "where did this file in the target rootfs come from" is a question you can now actually answer) but again you're not gonna remember this at all

# ? Nov 1, 2021 21:18

Poopernickel: Oct 28, 2005; electricity bad; Fun Shoe

DoomTrainPhD posted:

And at what point does the design complexity get complex enough that Buildroot goes bad?

Effortposting because I'm on paternity leave right now.

There are a few areas where Buildroot's limits really show IMO:

1. There isn't a slick way to subclass a design. Like say, maybe I want:
- Base_design
- Base_design + customization_a
- Other_design = (Base_design + customization_b)
- Other_design + customization_b

You can kind of do it with defconfig fragments that you assemble before running Buildroot's Make. I've also seen Buildroot defconfigs generated using the C preprocessor as a workaround. But in either of these flows, you need a bunch of custom tooling that Buildroot doesn't know about. Both of them also make it really hard to use menuconfig, and invite option conflicts/dependency issues because you can't use savedefconfig any more.

2. Buildroot isn't good at sharing host tools, or packages generally. If I want to build 10 images that are almost the same except for a couple of installed packages and maybe a couple of package configs, it's dumb to recompile all the host-side tools over and over again. You can set a common hostdir, but Buildroot isn't smart enough to know whether that's safe or not.

3. Buildroot doesn't have any concept of "maybe there should be different image formats". Instead, you just have a shell-script where you have to janitor it all yourself. And good luck if you want to sometimes just build _one_ format, and sometimes all of them.

4. It's hard to tweak a recipe's behavior slightly in a br2-external layer.

5. It's hard to express "this image should contain some other defconfig's .img.gz on the root filesystem somewhere", especially in a way that can track dependencies or share identical packages without rebuilding.

6. Package dependencies don't have any linkage with Kconfig dependencies, so it's hard to keep them in sync across a large set of custom packages.

7. All Makefiles are in a global namespace, meaning you can modify anything from anywhere. But it's hard to reason about the parsing order, and also most recipes have stateful things that happen in their pkg-foo calls at the end.

8. It's hard to customize the behavior of a recipe without editing the package's Makefile directly. Yes, you can have a .mk in your external layer that adds to a few variables. But there isn't really a way to hook something right before the recipe calls its pkg-foo. So you're stuck trying to reverse engineer what that file does and how, or you're stuck

Rather than deal with that, it seems like a lot of companies just keep an internal Buildroot fork instead, which kind of sucks once it's upgrade time. Overall it's a much harder thing that Yocto's layers/bbappend system.

9. Weirdly, there's no easy mechanism to say "copy these 5 files into the source-tree post-patch". And no real way to say "copy 4 files into the package's work tree, apply a patch, then copy some more files." Yes, you can hook into the steps. But it's not particularly easy to do.

10. There's also no easy way to say "Build my rootfs with 64MB extra, whatever size that winds up being".

Poopernickel fucked around with this message at 21:39 on Nov 1, 2021

# ? Nov 1, 2021 21:34

FlapYoJacks: Feb 12, 2009

A quick note about the above point: "- hope you like clean builds when you make any change other than "adding something to the build that was not previously being built"

Buildroot now has per-package directory building much like yocto! So if you want to rebuild a package with an updated dependency, it's generally:

- Remove the dependent package and the package that uses the package from the per-package/ and build/ directories
- Rerun `make ${package}`

It's quite nice!

# ? Nov 1, 2021 21:38

Sapozhnik: Jan 2, 2005; Nap Ghost

The Freedesktop Runtime project used to use Yocto but then they made something called Buildstream to replace it, I wonder if that's any good.

There isn't really any ready to go set of build scripts like Yocto for it though unless you count, well, the Freedesktop Runtime.

# ? Nov 1, 2021 21:39

Poopernickel: Oct 28, 2005; electricity bad; Fun Shoe

DoomTrainPhD posted:

A quick note about the above point: "- hope you like clean builds when you make any change other than "adding something to the build that was not previously being built"

Buildroot now has per-package directory building much like yocto! So if you want to rebuild a package with an updated dependency, it's generally:

- Remove the dependent package and the package that uses the package from the per-package/ and build/ directories
- Rerun `make ${package}`

It's quite nice!

I've seen that, yeah - exciting stuff. Is it reliable yet?

I've also been wondering if it could work to dump all of a package's expanded variables and then hash them, to finally get the ability to know whether a package needs rebuilding or not. Got any thoughts on whether that's possible?

# ? Nov 1, 2021 21:41

FlapYoJacks: Feb 12, 2009

Effort replying because I'm avoiding work. :v:

Poopernickel posted:

Effortposting because I'm on paternity leave right now.

There are a few areas where Buildroot's limits really show IMO:

1. There isn't a slick way to subclass a design. Like say, maybe I want:
- Base_design
- Base_design + customization_a
- Other_design = (Base_design + customization_b)
- Other_design + customization_b

You can kind of do it with defconfig fragments that you assemble before running Buildroot's Make. I've also seen Buildroot defconfigs generated using the C preprocessor as a workaround. But in either of these flows, you need a bunch of custom tooling that Buildroot doesn't know about. Both of them also make it really hard to use menuconfig, and invite option conflicts/dependency issues because you can't use savedefconfig anymore.

Agreed.

That's why I made the above docker-init system that handles this particular failing. Unfortunately, that also does indeed mean you can't use savedefconfig, so adding to the existing defconfigs is generally a meld operation which is meh.

Poopernickel posted:

2. Buildroot isn't good at sharing host tools, or packages generally. If I want to build 10 images that are almost the same except for a couple of installed packages and maybe a couple of package configs, it's dumb to recompile all the host-side tools over and over again. You can set a common hostdir, but Buildroot isn't smart enough to know whether that's safe or not.

Also agree, although luckily with ccache host-tools generally take very little time to compile, and usually there isn't a lot of them, but yes, agreed, although not a deal breaker.

Poopernickel posted:

3. Buildroot doesn't have any concept of "maybe there should be different image formats". Instead, you just have a shell-script where you have to janitor it all yourself. And good luck if you want to sometimes just build _one_ format, and sometimes all of them.

Image formats such as .img and .tar.gz? Can you clarify?

Poopernickel posted:

4. It's hard to tweak a recipe's behavior slightly in a br2-external layer.

Yes, and you shouldn't. Either make a new recipe and use that, or patch the existing .mk file. If we allowed people to purposefully tweak recipes from outside of their respective makefiles on a normal basis, you end up with a bunch of malformed garbage recipes all over the place like Yocto has.

Poopernickel posted:

5. It's hard to express "this image should contain some other defconfig's .img.gz on the root filesystem somewhere", especially in a way that can track dependencies or share identical packages without rebuilding.

Yep, that's why I made the above init system. :v:

It builds in order from top to bottom, and then a post-image.sh script copies the .img.gz to the appropriate place.

Poopernickel posted:

6. Package dependencies don't have any linkage with Kconfig dependencies, so it's hard to keep them in sync across a large set of custom packages.

I'm not sure what you mean by this. :smith:

Poopernickel posted:

7. All Makefiles are in a global namespace, meaning you can modify anything from anywhere. But it's hard to reason about the parsing order, and also most recipes have stateful things that happen in their pkg-foo calls at the end.

Poopernickel posted:

8. It's hard to customize the behavior of a recipe without editing the package's Makefile directly. Yes, you can have a .mk in your external layer that adds to a few variables. But there isn't really a way to hook something right before the recipe calls its pkg-foo. So you're stuck trying to reverse engineer what that file does and how, or you're stuck
Rather than deal with that, it seems like a lot of companies just keep an internal Buildroot fork instead, which kind of sucks once it's upgrade time. Overall it's a much harder thing that Yocto's layers/bbappend system.

This is by design to avoid Yocto-recipe layer messes. If you want an external tree/layer, you can! I always have an external tree directory for my clients.

Poopernickel posted:

9. Weirdly, there's no easy mechanism to say "copy these 5 files into the source-tree post-patch". And no real way to say "copy 4 files into the package's work tree, apply a patch, then copy some more files." Yes, you can hook into the steps. But it's not particularly easy to do.

??? Every package has a ${PKG_PRE_PATCH_HOOKS} and ${PKG_POST_PATCH_HOOKS} variable that executes a defined macro in the respective .mk file. IE:

Makefile code:


define MY_PKG_COPY_FILES_PRE_PATCH
	cp $(MY_PKG_PKGDIR)/pre_patch/these_files $(@D)
endef
MY_PKG_PRE_PATCH_HOOKS += MY_PKG_COPY_FILES_PRE_PATCH

define MY_PKG_COPY_FILES_POST_PATCH
	cp $(MY_PKG_PKGDIR)/post_patch/these_files $(@D)
endef
MY_PKG_POST_PATCH_HOOKS += MY_PKG_COPY_FILES_POST_PATCH

Seems pretty easy to me.

Poopernickel posted:

10. There's also no easy way to say "Build my rootfs with 64MB extra, whatever size that winds up being".

That's... not a terrible idea and I will bring that up with the developers!

FlapYoJacks fucked around with this message at 22:00 on Nov 1, 2021

# ? Nov 1, 2021 21:53

FlapYoJacks: Feb 12, 2009

Poopernickel posted:

I've seen that, yeah - exciting stuff. Is it reliable yet?

I've also been wondering if it could work to dump all of a package's expanded variables and then hash them, to finally get the ability to know whether a package needs rebuilding or not. Got any thoughts on whether that's possible?

It's quite reliable but not out of the "experimental" menuconfig option yet. :smith:

I use it in production though. There are some drawbacks that are being addressed right now, specifically with the `make sdk` command.

# ? Nov 1, 2021 21:54

FlapYoJacks: Feb 12, 2009

Quick note: If anybody uses Buildroot AND has a client that uses AWS-IoT or likes pain, I have a repository of all of the relevant AWS-IoT packages ported to Buildroot: https://github.com/aduskett/buildroot-aws-iot

# ? Nov 1, 2021 21:58

FlapYoJacks: Feb 12, 2009

I made an embedded Linux thread: https://forums.somethingawful.com/showthread.php?threadid=3983655

# ? Nov 1, 2021 22:17

SYSV Fanfic: Sep 9, 2003; by Pragmatica

This entire discussion makes me grateful I'm a cripple with a diseased spine and broken brain on ssdi.

# ? Nov 1, 2021 22:24

rotor: Jun 11, 2001; classic case of pineapple derangement syndrome

SYSV Fanfic posted:

. The unix philosophy is predicated on a set of pre-suppositions about computers that no longer hold for the bulk of computer users.

i dont agree.

# ? Nov 1, 2021 22:32

rotor: Jun 11, 2001; classic case of pineapple derangement syndrome

here's the precepts of the Unix Philosophy, as I am familiar with them. There are other versions but they are largely similar. We will not be discussing esr or any of his lovely opinions.

Small is beautiful.
Make each program do one thing well.
Build a prototype as soon as possible.
Choose portability over efficiency.
Store data in flat text files.
Use software leverage to your advantage.
Use shell scripts to increase leverage and portability.
Avoid captive user interfaces.
Make every program a filter.

# ? Nov 1, 2021 22:34

Progressive JPEG: Feb 19, 2003

BlankSystemDaemon posted:

The ports collection is a hierarchy of Makefiles and (usually) a few patches that get applied at build-time, in order to fix Linuxisms. However, since it was introduced in 1994,

gee, who wouldn't want to debug this

# ? Nov 1, 2021 23:04

SYSV Fanfic: Sep 9, 2003; by Pragmatica

hobbesmaster posted:

iiot gateways. ie, very slow telemetry and control protocols both wired (rs485,232, etc) and wireless (LoRa, BLE) to a wan, cellular or Ethernet.

the problem with armv5 (arm9) is that software interrupts are slow as molasses so while you might think a 400mhz processor would be more than capable of a certain task you can certainly overload it very easily with threads. as a result a cortex-a5 at similar or lower speeds can handle tasks significantly faster because the interrupt controller is just so much faster.

oh also software float. this would be fine (ish) except for the entire �run JavaScript on everything� movement. did you know node.js supported software fp until like 2018?

Ah yeah, so dbus at a minimum would double the context switch. Also, I like your funny posts even if I don't quote them.

rotor posted:

here's the precepts of the Unix Philosophy, as I am familiar with them. There are other versions but they are largely similar. We will not be discussing esr or any of his lovely opinions.

1. Small is beautiful.

2. Make each program do one thing well.

3. Build a prototype as soon as possible.

4. Choose portability over efficiency.

5. Store data in flat text files.

6. Use software leverage to your advantage.

7. Use shell scripts to increase leverage and portability.

8. Avoid captive user interfaces.

9. Make every program a filter.

It still has it's merits for developers. Throwing all of that away for the users resulted in two widely used linux based OSes (chromeOS and android).

I numbered the list to make it easier to talk about.

1&2 imply that interoperability with the rest of the system is less important than function. Kind of like having to work on a team with a bunch of talented people that can't work together. I think a lot of it is how you define "one thing". I consider ip great, because it does "network configuration". Other people hate it because it combines the "one thing" that individual utilities used to do.

4 applies mainly to unix to unix portability. The portability most people people care about now is either x86/arm or different operating systems that all have their own, separate API. I've got no data, just impressions and anecdotes, but software built according to this philosophy doesn't seem to be popular with most computer users on other operating systems.

6 is good and will always be relevant.

7 Shell scripts can be pretty dangerous though. Once upon a time steam client for linux silently deleted everything owned by my user on the entire computer (including my backup drive). I filed a bug report and made the front page of slashdot. They were using a shell script that broke because of the configuration of my system. I think python is better in most cases, but you could argue you're just replacing one scripting language with another.

9 is still pretty good, so much so that microsoft aped it for powershell and cmdlets.

I personally like being able to go to KDE control panel and configure system wide settings. I do less and less in the shell every year. Usually just stuff for hobbyist microcontroller sdks like esp32 or pico.

# ? Nov 1, 2021 23:23

Progressive JPEG: Feb 19, 2003

rotor posted:

here's the precepts of the Unix Philosophy, as I am familiar with them. There are other versions but they are largely similar. We will not be discussing esr or any of his lovely opinions.

Small is beautiful.

Make each program do one thing well.

Build a prototype as soon as possible.

Choose portability over efficiency.

Store data in flat text files.

Use software leverage to your advantage.

Use shell scripts to increase leverage and portability.

Avoid captive user interfaces.

Make every program a filter.

among these i think the following in particular don't work and in fact nowadays you're better off doing the opposite of what they dictate:

> Small is beautiful
> Make each program do one thing well.

i think these are more or less the same thing, and "one thing" is defined as "my use case"

tar, grep, sed, cc, ld, etc each have dozens of flags, since "one thing" is meaningless

> Choose portability over efficiency.

i think the fact that this was included is mostly an artifact of an era when building things that worked across cpu architectures wasnt as straightforward as it is today

i don't think it translates very well to e.g. talking to standardized services. mainly thinking of e.g. using only "standard" SQL because you end up with a lot of weird baggage that the nonstandard extensions have since fixed. and "support" for a standard doesn't mean it's 100% compatible so you still end up needing to debug each implementation anyway

it also feels like it's in direct conflict with "Build a prototype as soon as possible."

> Store data in flat text files.

csv hell

> Use shell scripts to increase leverage and portability.

shell scripts as a tool only decrease portability up-front, since they require that certain programs be installed and that they behave as expected by the original author
for example see behavior of 'sed -i' on linux vs osx/bsd
writing a python script, go program, or hell even javascript against their respective standard libraries is way more portable but that didn't exist yet at the time so all they had were lovely shell scripts

in summary i think most of the unix philosophy can be treated as a historical artifact of the environment where it came from

don't sign

# ? Nov 1, 2021 23:25

rotor: Jun 11, 2001; classic case of pineapple derangement syndrome

SYSV Fanfic posted:

Ah yeah, so dbus at a minimum would double the context switch. Also, I like your funny posts even if I don't quote them.

It still has it's merits for developers. Throwing all of that away for the users resulted in two widely used linux based OSes (chromeOS and android).

I numbered the list to make it easier to talk about.

1&2 imply that interoperability with the rest of the system is less important than function. Kind of like having to work on a team with a bunch of talented people that can't work together. I think a lot of it is how you define "one thing". I consider ip great, because it does "network configuration". Other people hate it because it combines the "one thing" that individual utilities used to do.

4 applies mainly to unix to unix portability. The portability most people people care about now is either x86/arm or different operating systems that all have their own, separate API. I've got no data, just impressions and anecdotes, but software built according to this philosophy doesn't seem to be popular with most computer users on other operating systems.

6 is good and will always be relevant.

7 Shell scripts can be pretty dangerous though. Once upon a time steam client for linux silently deleted everything owned by my user on the entire computer (including my backup drive). I filed a bug report and made the front page of slashdot. They were using a shell script that broke because of the configuration of my system. I think python is better in most cases, but you could argue you're just replacing one scripting language with another.

9 is still pretty good, so much so that microsoft aped it for powershell and cmdlets.

I personally like being able to go to KDE control panel and configure system wide settings. I do less and less in the shell every year. Usually just stuff for hobbyist microcontroller sdks like esp32 or pico.

1&2 imply nothing of the sort imo.

4 applies to everything, not just unix-to-unix.

7 in context, 'shell script' would include python, ruby, perl, nodejs and the rest.

# ? Nov 1, 2021 23:29

SYSV Fanfic: Sep 9, 2003; by Pragmatica

Just becoming a dumb luser that doesn't have the mental fortitude to janitor their computer was pretty eye opening. Poettering seems like a prick, but he was right about processes hanging around after you logout. Anymore rather than using screen on my desktop I just lock the desktop session. The people who want the old behavior can opt in, but it kinda sucks having an orphaned process you have to hunt down b/c it's blocking access and breaking your desktop.

# ? Nov 1, 2021 23:30

rotor: Jun 11, 2001; classic case of pineapple derangement syndrome

Progressive JPEG posted:

among these i think the following in particular don't work and in fact nowadays you're better off doing the opposite of what they dictate:

> Small is beautiful
> Make each program do one thing well.

i think these are more or less the same thing, and "one thing" is defined as "my use case"

Yes, i agree. Your program should cover one use case and cover it well.

quote:

i don't think it translates very well to e.g. talking to standardized services. mainly thinking of e.g. using only "standard" SQL because you end up with a lot of weird baggage that the nonstandard extensions have since fixed. and "support" for a standard doesn't mean it's 100% compatible so you still end up needing to debug each implementation anyway

I dont really understand what you're saying here. Are you saying we SHOULD use weird nonstandard SQL extensions?

quote:

> Store data in flat text files.

csv hell

It says "store data in flat text files" not "find the worst format you can find to store your text in." Its "text file" in opposition to "binary files with records and fields at particular byte offsets"

quote:

shell scripts as a tool only decrease portability up-front, since they require that certain programs be installed and that they behave as expected by the original author
for example see behavior of 'sed -i' on linux vs osx/bsd
writing a python script, go program, or hell even javascript against their respective standard libraries is way more portable but that didn't exist yet at the time so all they had were lovely shell scripts

quote:

in context, 'shell script' would include python, ruby, perl, nodejs and the rest. Probably java too.

# ? Nov 1, 2021 23:36

rotor: Jun 11, 2001; classic case of pineapple derangement syndrome

Progressive JPEG posted:

tar, grep, sed, cc, ld, etc each have dozens of flags, since "one thing" is meaningless

and for the record, 'ls' is widely held up as one of the least unix-like programs there is

# ? Nov 1, 2021 23:38

Progressive JPEG: Feb 19, 2003

rotor posted:

and for the record, 'ls' is widely held up as one of the least unix-like programs there is

but it just lists files, and that's one thing!

# ? Nov 1, 2021 23:54

rotor: Jun 11, 2001; classic case of pineapple derangement syndrome

Progressive JPEG posted:

but it just lists files, and that's one thing!

no it also sorts the list, and has flags for what to display and so forth, the Perfect Unix Utility would just list the file information in some maximal way and you'd write your own shell script(s) to filter and sort them.

# ? Nov 1, 2021 23:55

Progressive JPEG: Feb 19, 2003

i guess what i'm getting at wrt that specifically is that either you're going to have a small number of commands with long manpages, or a large number of commands with short manpages

at least with the long manpages you can remember to look at 'man ls' for functionality relating to list files, rather than needing to remember the distinct top-level command for showing file sizes

# ? Nov 1, 2021 23:56

rotor: Jun 11, 2001; classic case of pineapple derangement syndrome

like i'm not sure if you're getting hung up on the one-sentence summary of the precepts or what, my advice is to actually read The Unix Philosophy by Gancarz, its pretty short and pretty readable and still mostly relevant after all this time.

# ? Nov 1, 2021 23:57

Shaggar: Apr 26, 2006

rotor posted:

here's the precepts of the Unix Philosophy, as I am familiar with them. There are other versions but they are largely similar. We will not be discussing esr or any of his lovely opinions.

Small is beautiful.

Make each program do one thing well.

Build a prototype as soon as possible.

Choose portability over efficiency.

Store data in flat text files.

Use software leverage to your advantage.

Use shell scripts to increase leverage and portability.

Avoid captive user interfaces.

Make every program a filter.

lol the unix philosophy is dumb as hell

# ? Nov 1, 2021 23:57

Adbot: ADBOT LOVES YOU

# ? Apr 16, 2024 13:49

rotor: Jun 11, 2001; classic case of pineapple derangement syndrome

Shaggar posted:

lol the unix philosophy is dumb as hell

hey shagger how you doin

# ? Nov 1, 2021 23:58

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > Linux: vim isn't moe

«‹›1091 »