bboozzoo

Yes, completely. If there's no business contract in place, it's hard to expect compensation of any sort. It's all hinged on the other party's willingness to recognize the value in keeping the project alive. Very few do.

I don't think anyone is expecting you to donate to literally every project you use. However, say your business is to build and sell a product done in JS. You already have a bunch of JS devs, whom you may have even bought those sweet MacBooks. Let's also say, you're invested in keeping the code quality high, which you boast about in your product web page. Why not donate a $100/month to the JSLint project which is part of your toolchain anyway and helps you achieve your goals? The annual cost is probably less then you'd spend on the toilet paper for the office. You get a maintained product, they get some money to support their efforts. It's clearly a win win.

For starters, assuming the Linux variant, build a statically compiled application, pack it into an initramfs as the only file there, for simplicity name it `/init`, bundle the initramfs with the kernel, boot. At this point, your app should be the PID 1 and the only process running (with the exception of a bunch of kernel threads). At this point you can do whatever you want.

Geee, wondering what the victims would say about this. Oh wait..

> This is the same technique used in Go and many others for preemption. If you don't add this, futures that don't yield can run forever, stalling the system.

You may be referring to this particular issue in Go https://github.com/golang/go/issues/10958 which I think was somewhat addresses a couple releases back.

The first one is indeed non-obvious, but the remaining snippets presented as bugs would not pass a review unless hidden inside 1k+ LOC PRs. Some are so blatantly obvious (seriously for loop and not passing current value as variable?) that I'm surprised that authors have listed them as if they're somehow special.

What's the last one?

> It's not really about motivation. Difficulty of terminating employment can make employees a real liability when you're small if they turn out to be a bad fit.

Given significantly smaller salaries and the typical 3-6 months probationary period before going full time, I don't think this is much of a risk. If someone turns out to be a 'bad' fit 6 months in, the employee isn't the only thing in need of looking into.

Storm in a teacup? It's not like this is the most wasteful package on the system, so I don't see where the drama is. If you're building a minimal image based on Ubuntu, just go ahead and apply the workaround, or remove the files. If you're rebuilding the whole distro, drop the package and fix the deps to your liking.

Putting emphasis on Good codebase. I'm afraid in practice good codebases are few and far between (the companies). Doesn't mean we should not try to make them better.

This made me chuckle a bit. The polish government can hardly contract appropriate levels coal so that people who burn it to heat their homes have trouble replenishing their supplies before winter. Just yesterday they came up with 50% tax on excessive income for companies which employ 250+ people, so clearly they aren't capable of planning months or years ahead, let it be the effects of such a strike on NS.

Have you tried json-mode? Seems to work pretty well.

From readme in tehir github repo:

> The name Massa is due to a river near the Eiger mountain in Switzerland

Even though HN crowd is US centric, there are people, cultures, languages and places outside of US too.

I think my main problems with AppArmor are the feature set isn't coherent across all distros that use it and it isn't integrated too well with audit tools. OpenSUSE ships distro patches that are a major hack to make ausearch properly show AA denials, while others need to look at dmesg and remember to disable printk ratelimit. The supported feature set is fun, the kernel mainline vs Ubuntu vs SUSE feature sets differ a lot. Ubuntu supports fine grained socket mediation (as in specific ops) & dbus. OpenSUSE supports some of the socket mediation, but as life has demonstrated some rules that work on Ubuntu are incorrectly downgraded and for instance all unix socket access gets blocked (though thanks to the AppArmor folks this got fixed now). Arch which I'm considering to be close to mainline has no dbus and no fine socket mediation. In theory one can use the same policy file on all systems, but the way it gets downgraded is not always predictable. At least the features are somewhat discoverable though /sys/kernel/security/apparmor tree, but I don't know what happens when say the kernel reports dbus mediation, but dbus-daemon was built without it. Then there are also some missing features, I think the abstract socket mediation is still not there. Lastly, the parser is super slow and memory hungry, especially when throwing some AARE heavy profiles at it. It happens that Ubuntu Core makes heavy use of apparmor profiles to lock down snaps on embedded Linux devices, and all the timings data that we collect show calling out to apparmor parser taking the largest chunk of the snap installation time.

FWIW mediation of dbus & network is already supported by SELinux in all implementations I've tried, but then SELinux has a separate set of warts. Eg. trying to use the same source policy and building it on hosts with different tooling/refpolicy. Using `optional_policy` doesn't cut it if types are not known at all, and as debugged with good folks from #selinux, the only way to work around this was using `ifndef` and passing defines to m4 interpreter.

It still requires a process to run. AFAICT the probe only puts an entry in a map, which a userspace process reads from and launches a shell. So, while the triggering mechanism remains hidden, the process that launches the shell needs to take more steps to hide itself. Once it starts pinning the map (which is only possible to do within the bpf fs), it probably has to employ various tricks like unshare to a new mount ns to mount a new instance of bpffs. At the same time, the shell-spawning-process need to have enough privileges to load a BPF program in the first place.

That's funny as the thread is about contrasting Russia with US, but I don't seen to recall US invading any neighboring countries under the false pretense of defending some minorities.

Canonical directly maintains only a handful of snaps, and even so it's up to the individual teams to do the relevant QA before publishing a version to the stable.

You'd expect that publishers follow the same process, that a stable channel means it's really stable, whereas version breaking changes really end up in per version channel. Ideally you have the latest/{stable,beta,candidate,edge} which follows the latest version of the software, and eg. v1/{stable,beta,candidate,edge}, v2/{stable,beta,candidate,edge}, v3/{stable,beta,candidate,edge} for individual version. A simple concept but surprisingly hard to follow.

Maybe the publishers are really lazy and don't care about the users or the maintenance cost of keeping n versions around is just too high, in which case it's up to the users to make their effort worth it.

But then you can't really blame Canonical and that makes the wole agument moot.

> big Linux companies

I'm not sure the company can be considered a big one. The headcound was like ~600 last time I checked. Compare that with SUSE (~2k) and RH (~12k, bet just their engineering is more than the whole of Canonical).

Raccoons were introduced in Europe by humans, but badgers are native to Europe and they are equally interesting mammals. Although your chances of spotting a badger in the wild, at least in Poland, are much lower than for the racoons in the US.

Yocto/OE used to build Go in this shared mode just to conserve space that would otherwise be wasted by each Go program shipping its own copy of the standard library. It did shave off some MBs, so hard to say it wasn't useful especially if a bunch of +20MB binary blobs are a concern.

Haven't played CP so I can't comment on this specific aspect, but actions like hacking, taking over cameras, robots, or augmenting your character were already present in earlier tiles. Specifically, Deus Ex can be praised here. The hacking mini games were great, while augmentations opened many new ways to complete the missions, dramatically changing the gameplay.

More like `nohup application | ts >> log.txt &`

> Industry sanctioned nepotism doesn't feel like a good look for the SWE industry

Is it nepotism though? Your friends are not your family. Unless I'm missing some fine details of what nepotism means as a non native English speaker.

Besides, if you are a reliable employee, I doubt any reasonable company would miss out on an opportunity to consider a strong referral. Regardless of industry.

What in your view makes defer a bad feature of Go? Maybe my bar is low, but each time I jump back to C I wish I had defer and end up abusing __attribute__((cleaup)) instead.

Ultimately it's not the maintainer's role to waste hours untangling the this mess. I do want ripgrep, but I see no value in forcing any particular version of ripgrep's dependencies on other rust programs that happen to use the same crate.

There is a similar problem with Go dependencies in Debian (and Fedora for that matter). I'm not entirely convinced it still makes sense to insist on splitting the dependencies and mixing their versions stunningly at random hoping that if the build succeeded the resulting artefact works lin a fashion that the upstream developer intended. If the problem is about reproducibility, the upstream is already free to specify their desired versions of libraries, so why not treat the whole package (with vemdored dependencies) as a single artifact and call it a day? It's not like those dependencies can be separately updated like shared libraries. Packaging node apps this way would be pure madness, it's only that neither Rust nor Go have reached the same level of dependency hell that discussions like this are even held.

How is this even a surprise?

> I think the solution to that should be something other than removing the sandbox. I see "portals" referred to elsewhere in this thread w.r.t. flatpak; does snap not have similarly?

Snaps use portals like flatpaks do. The problem is more about frameworks you build applications with not being ready to consume portals. Turns out only some reasonably recent Qt versions can work with portals. IIRC Electron only landed support couple of months ago. Back on the host side of confinement, you need to run a reasonably recent xdg-desktop-portal (and a maching GUI integration bit). Some old distros do not provide any of those packages or ship version that don't work, so things are DOA.

> Snap has the abysmally named "--classic" parameter to allow installs to "run without confinement".

Only if the snap was built with classic confinemnt in mind. Otherwise, just slapping --classic on a random snap does nothing, there's even a warning display about that. Classic is very much the same as a random 3rd party vendor app built and unpacked under /opt. Unfortunately some software, especially IDEs and languages are unsuitable for running under confinement and need to be distributed this way. By passing --classic you give your consent to use an app package in this sub-par way.

FWIW, perhaps you meant --devmode, which as the name implies is mostly for developing a snap? snap install --help describes that as:

    --devmode  Put snap in development mode and disable security confinement