ninjin

The uniqueness of the situation is that OpenAI et al. poses as an intelligent entity that serves information to you as an authority.

If you go digging on darkweb forums and you see user Hufflepuffed47___ talking about dosages on a website in black and neon green, it is very different from paying a monthly subscription to a company valued in the billions that serves you the same information through the same sleek channel that "helps" you with your homework and tells you about the weather. OpenAI et al. are completely uprooting the way we determine source credibility and establish trust on the web and they elected to be these "information portals".

With web search, it is very clear when we cross the boundary from the search engine to another source (or it used to be before Google and others muddied it with pre-canned answers), but in this case it is entirely erased and over time you come to trust the entity you are chatting with.

Cases like these were bound to happen and while I do not fault the technology itself, I certainly fault those that sell and profit from providing these "intelligent" entities to the general public.

Not sure if it was called "beta" or "alpha" and "closed" is of course up to interpretation, but it was indeed by invitation. Swedish law at the time (still?) had a clause about permitting sharing copyrighted material within a limited circle, which I know Spotify engineers referred to as somewhat legitimising it. I also know for a fact that once the invite-only stage ended there was a major purge of content and I lost about half of my playlist content, which was the end of me having music "in the cloud". Still, this is nearly twenty years ago, so my memory could be foggy.

Correct, the pirated music library was before they exited the closed Alpha.

Firstly, thank you for engaging and trying to enlighten me.

I do understand why capability delegation is useful and I am familiar with using Unix sockets to delegate the control of daemons using socket permissions, which feels similar to what we see here with capsudod (I have not read the code sadly, too much other code to read today).

However, I am still puzzled what the advantage of having a herd of capsudod instances running is to say my proposal of allowing users to set up their own doas.conf(5)s to delegate capabilities. Yes, we still need SUID and we will need to be darn sure 1,000 or so lines are properly secured, but it is attenuable, revocable, auditable, and feels (perhaps wrongly, because I have a bias towards text files describing the state of a system?) more natural to me than putting it all into the running state of a daemon.

Is there some other strength/weakness of these approaches that I am failing to see? I am no systems programmer, but I find topics like this interesting and dream of a day when I could be one.

I am somewhat cautious to comment as I know the author is way more experienced than I am and I fear that I may be missing something. However, let me try to accomplish the same with my elementary doas(1) knowledge.

Allowing mounting for a specific group is simple with doas.conf(5):

    permit :mountd cmd /sbin/mount
    permit :mountd cmd /sbin/umount

We can of course tighten it further as the author did:

    permit :mount-usb cmd /sbin/mount /dev/sdb1
    permit :umount-usb cmd /sbin/umount /media/usb

If you want to go more complex than specifying arguments, we could of course create a shell script and specify it instead of a binary.

Likewise, we can do something similar for a service account:

    permit :www-deployment as www-deployment cmd /var/www/bin/build /var/www/application

The key difference here would be that www-deployment can not delegate as easily to arbitrary users, as they would need to ask someone with root access to add additional users to the www-deployment group. But I am left wondering if this use case (if it is important enough) is not equally well served by specifying a location for non-root users to add permissions akin to what we see in doas.conf(5), but with the constraint that they of course can only allow other users to run commands with their privileges. Yes, it would "bloat" doas(1), but these code paths are not that long as long as you keep your scope constrained (doas(1) has a core of just over 500 lines and with environment handling and configuration format parsing we arrive a a final line count at just over 1,300).

At this point, the main advantage I see with capsudod is that you can more easily drop privileges and put in restrictions like pledge(2) before the binary is ever called upon by whatever user we have granted permissions. While with the doas(1) thinking above you have to run over plenty of code that could be exploited. Still, this feels like a rather minor relative improvement to what we already have.

Am I missing something in my ignorance? Lastly, let me also say that I am sure that sudo(8) has the ability to do the same things I proposed to do with doas(1) above, but I know the latter far better.

Having played the Famicom Disk System, I will also say that the load times are abysmal. I think it is Castlevania II that has an autosave function for the Japanese release which was for the FDS and it is so darn slow that I would recommend against playing it even if you can read Japanese.

Thank you for sharing the write up!

Not an OpenBSD expert by any means, but two small pieces of minor feedback as everything else you wrote mirrors my own setup and experience. Firstly, unless you are really strapped for space on say a 90s machine, it is generally recommended to install all the file sets as there can be interactions with ports even if one does not expect it (say ffmpeg needing X11 libraries). The general OpenBSD mindset is after all "Use the defaults" and the default is to install all the file sets. Secondly, the OpenBSD Handbook has a bit of a mixed reputation in the community from what I can tell. Unlike the FreeBSD Handbook, it is not an official document and I tend to rely on man pages, openbsd.org, misc@, and a few blogs I consider to be trustworthy instead.

As a final note, glad to see you have IPv6 up and running. I really should get around to it now that dhcp6leased has been in base for more than two releases.

I disagree, but maybe it is a cultural thing for those of us that are more used to functional styles of programming? I was taught method chaining as a style by a seasoned JavaScript and Ruby programmer myself and I do not find the semantics confusing. "Create X with Y set to 17 and Z to 4711" can be either on one or three lines to me, as long as the method calls are clear and short enough.

As for variables, I (again personally) find it taxing to have many variables in scope, so I do net see their presence as a universal good. If we instead simply use expressions, then there is no need to concern yourself with whether the variable will come into play later on. Thus, I think it increases clarity and favour that over the ease of future modification argument you propose (heck, I would argue that you get better diffs even if you force the variable declaration into a future modification).

As for bikeshedding this piece of code further, if I steal some ideas from chrismorgan [1] and embedding-shape [2] who appear to be way more seasoned JavaScript programmers than me:

    const $t = document.createElement('table');
    for (const r of
            [
                ['one',  'two',  'three'],
                ['four', 'five', 'six'  ],
            ]) {
        const $r = $t.insertRow();
        for (const e of r)
            $r.insertCell().innerText = e;
    };
    document.body.append($t);

This is now rather minimal and the logic is easy (for me) to follow as the scopes are minimal and namespace uncluttered. It was a rather fun little exercise for a language I am not overly familiar with and I learned a few tricks and perspectives.

[1]: https://news.ycombinator.com/item?id=45782938

[2]: https://news.ycombinator.com/item?id=45781591

Cheers! Fixed.

Really? The variable name lengths? Not that the code is clearer as:

    const te = document.createElement('table');
    document.body.appendChild(te);
    [
        ['one',  'two',  'three'],
        ['four', 'five', 'six'  ],
    ].forEach((r, i) => {
        const re = te.insertRow(i);
        r.forEach((c, j) => {
            re.insertCell(j).innerText = c;
        })
    });

My personal stance on short variable names is that they are fine as long as their scope is very limited, which is the case here. Rather, the "crime" to me is an overuse of rather pointless variables as the majority of them were only used once.

Disclaimer: I have not tested the code and I only write JavaScript once every few years and when I do I am unhappy about it.

I mean, are we surprised? Linux has on the order of millions times more users and funds (probably not developers though, but who knows). Thus, if there is any financial viability of a port I am certainly expecting Linux to "move" first. Rather, I am impressed that OpenBSD and NetBSD are keeping up as well as they do.

It really is and not just that. WireGuard being natively supported makes configuring your peers as easy as dumping the last of these example lines into /etc/hostname.wg[0-9]:

https://man.openbsd.org/wg#EXAMPLES

Simple, text-file based configuration for everything in the extensive base system and no drama between upgrades is really what makes you a happy OpenBSD user.

It feels like Alpine tries to imitate the OpenBSD installer somewhat as well, but it is just not the same as it forces you to make choices between SSH servers, NTP daemons, etc. So, it still very much feels like the Linux "pick and mix box". What makes OpenBSD so special is that there is one choice, it tends to be a good choice, and it is the only choice they will support and therefore they will put in the hours to make it solid.

Yes, and OpenBSD being a fork of NetBSD still carries some of that spirit.

Which is why there is libevent [1]?

[1]: https://libevent.org

Unless I am mistaken, OpenBSD base even explicitly codes against the older libevent API internally and ships it with each release, despite at the very least supporting kqueue, and thus gains better portability for a number of their tools this way.

Personally, I just go with Posix select for small programs where performance is not critical anyway.

True, but it is worth mentioning that since Amazon Japan dropped using established delivery services and went with their own gig-based one their service has taken a drastic turn for the worse: Claims of having ringed the bell, despite not having done so; packages left outside, without having allowed them to leave them outside in the settings; big envelopes rammed into mail boxes and hanging ~1/4 outside, because they could not be bothered to use the delivery lockers; absolutely mad parking and driving with their "delivery cars"; impolite behaviour when delivering at your door; etc. With Japan Post and the regular delivery services I have never seen any of these things. Sure, Amazon fairs better than elsewhere, but even Japan is not immune.

This is art, so arguing about exact boundaries is pointless in my book. But can we at least agree that there is rather a big difference between "This is something that plays from a standard cartridge with a standard mapper on the Famicom/NES you have from your childhood" and "This is something that plays from a standard cartridge with a standard mapper on the Famicom/NES you have from your childhood with a modified superhuman-speed controller to in real time feed 16 times the amount of data of the largest cartridge ever released for the system"?

Fujifilm's whole X-mount series is wonderful and while I shoot "full-frame" M mount to remain interoperable between digital and film, there is no doubt in my mind that I would have a Fujifilm X-mount series if I only shot digital based on how much fun they have been when I have borrowed/tested them. Great "enthusiast level" cameras, great glass, solid build, everything has a button/dial, does not break the bank, and I actually know more than one professional photographer that shoots them and one of them even shooting sports!

It really is impressive, but it is also fair to point out that it uses the MXM-1 mapper which only came into existence in 2022 [1]. I find it pointless to argue whether it is "cheating" or not as the technology it uses was used for other consoles at the time and it is fun to see new mappers like this, but it is, again, very different compared to keeping it within the realm of original Famicom/NES mappers and limits.

[1]: https://somethingnerdy.com/unlocking-the-nes-for-former-dawn

Indeed, if you want to see what is possible with only a Famicom (or NES) itself you can have a look at Little Limit's incredible Bad Apple "port" [1]. This recording is from an emulator [2], but I know from personal experience that it plays perfectly fine on my "New Famicom" (HVC-101). This is not to detract from how amazing the posted ACE is, but it is indeed different in terms of data limitations.

[1]: https://littlelimit.net/bad_apple_2_5.htm

[2]: https://www.youtube.com/watch?v=eNU1lzr_m4Q

If so, are we observing a move towards Universal Suffrage in the Kingdom of the Nouns? [1]

[1]: https://steve-yegge.blogspot.com/2006/03/execution-in-kingdo...

Thank you for sharing. My solution has been to dump small scripts like this in ~/bin:

    #!/bin/sh
    
    set -eu
    
    k=$(pass ARG)
    oathtool -b --totp "$k"

reMarkable (1) user here since 2019, what does the software stack look like for the Supernote? The A6 looks interesting as a form factor for someone like me that uses it solely for note taking (all I want is a "non-linear notebook") rather than annotation and reading (I use a printer and scanner for annotation/feedback and an "ancient", never-online Kindle for reading books). reMarkable has always been open-ish rather than properly open, so I would hope for Supernote to be more open to the idea of users having access to code and control over their devices (even if I never connect my reMarkable to the network).

Sadly, traditional banks are very eager to get rid of dedicated multi-factor devices in favour of their own mobile applications. I have seen strong encouragement via nagging and some going so far as to start charging for physical multi-factor authentication devices.

Likely this gives them another way to milk information out of you, push their marketing onto to you, and saves them from having to manage physical devices. The obvious downside is of course a degradation in security and further cementing the duopoly and more or less forced participation in it that we as citizens have to endure.

They seem closely aligned with the Free Software Foundation (FSF), so I could very well imagine that being a major ideological reason not to want to work with Apple. Yes, Apple sometimes upstream patches and they do contribute to open source here and there, but they certainly are no FSF poster child. Intel on the other hand are about as open as it gets when it comes to their track record in the graphics space. I personally have nothing but admiration for Rosenzweig's work and I hope they will continue to find environments where they can flourish and do great things in the years to come.

Indeed, I had just started using them at that. No account needed, you just needed to set your contact to "mailto:$EMAIL" and get on with your day. Was nice to use them for a few domains so as to make sure I had a more diverse set of tried and tested issuers, with bonus points to Buypass for being outside the US as well (Norway).

Seconded, but hard to find for small boxes. I have seen in-band ECC on Asus Nucs, but that is as good as it gets from what I can tell.

All good options, just noting that based on some searches I made they all seem to lack serial ports compared to the Wyse if that is something you care about (I personally do). There could be variants out there though with serial ports and if would be happy to hear about them and even more happy if there are fanless variants/alternatives for those of us with very limited space at home and a need to avoid noise.

Quick search online tells me ~5W for the Dell Wyse 5070, which does not sound unrealistic as I have similar boxes that draw ~10W. So, 32 to 62kWh per year and then we have ~USD 6.5 to 13 per year assuming 20 cents per kWh which another online search told me was reasonably realistic for the US.