eterps

> Too bad I don't have the Hardware to run it.

Cloud GPUs is supported if that is an option:

https://github.com/Acly/krita-ai-diffusion/blob/main/doc/clo...

In the past, I used PARnet to connect two Amiga computers via the parallel port.

This was a time when computer networks were a novelty to me. The unique aspect of this setup was that the required cable could be made at home. The ability to access and browse the filesystem of another Amiga through PARnet was a special experience, especially given the technological context of that time.

AFAIK there is no way to follow instructions from somewhere that results in an actual working system. I think there's something experimental that works on top of a Smalltalk system, but that it's not able to work independently of that. I also don't remember all source code being available.

Oberon is able to run on actual hardware and works in various emulators.

I do love the research they did for STEPS though, it's unfortunate it didn't result into an actual release.

Good point, thanks.

rclone supports Google Photos as well: https://rclone.org/googlephotos/

FAQ: https://github.com/0x192/universal-android-debloater/wiki/FA...

Non-hierarchical, a bit like a key value store.

Indeed, Michael Franz's work was certainly impressive. It's unfortunate that the code readability of those parts didn't quite match up to the rest of the system.

I don't know of any other system that accomplishes as much with the same amount of code lines. It includes not just a kernel, but also a compiler, a dynamic linker, an editor, and an unusual blend of a desktop and command line.

It's not something you'd want to use today, but it's certainly worth studying. It's a wonderful lesson in keeping complex systems as simple as possible.

> without any app capabilities

So you'd use e-mail and SMS?

You can continue to use encryption just fine: https://f-droid.org/en/packages/org.sufficientlysecure.keych...

The problem would be with the messaging/media services that have EtoE encryption integrated in the same app.

I am not sure how buying a dumb phone solves anything.

> Hosting services affected include web hosting, social media, video streaming services, file hosting and cloud services

> Even personal storage that is not being shared, such as Apple’s iCloud, will be subject to chat control

This is new to me. In that case it looks like all services with encryption 'baked in' lose their effectiveness. And that encryption/decryption of text & data needs to be done independently of said service layer to regain privacy.

What if generic encryption apps would integrate with chat apps and the like? According to these rules the chat apps are still required to do scanning, but that will be done on encrypted data which seems pointless.

Unless the rules will be adapted at some point that general encryption needs to be scanned as well, but that would be impractical and undesirable for the EU as well.

Too bad this isn't directly supported in ~/.config/ it would make it very easy in combination with GNU stow or another dotfiles manager.

That's a false dichotomy. If research conclusively showed that banning CSAM leads to an increase in actual sexual assaults against children, it wouldn't mean we should permit CSAM. Rather, it would suggest that the strategy needs to be reconsidered. F.i. shifting focus to the root cause instead of focusing solely on the media distribution.

> AI-generated, or just old-fashioned photoshop exist

Aren't those considered CSAM as well? At least as far as the EU Chat Control proposal is concerned?

BTW, you raise an interesting point about the argument being a variant of the trolley problem.

> Almost no one would disagree that removing all instances of CSAM from the internet would be a good thing, whether it's a "human problem" or not. That's not really the issue.

Would removing all instances of CSAM from the internet be a good thing if it would lead to an increase in CSA? After all the human problem still exists after removing CSAM.

It's difficult to find pictures of it, but this one is close to how I remember it: https://i.pinimg.com/1200x/b3/0d/94/b30d94aaec9669bc45fd0f23...

Is there a way to know which alternatives don't contain lead?

I would love to be able to import the Project Oberon source code into an LLM, gain a deep understanding of it, and subsequently generate smaller subsets of the system (or variants like a CLI based system). Additionally, I'm interested in the potential to convert it into other programming languages, such as Nim, Go or Odin.

It seems that at the moment LLMs are not able to grok Oberon source code (although they are able to generate it).

In case you want to download the complete thing:

wget -r -np -nH --cut-dirs=3 -R '.html,.tmp' https://people.inf.ethz.ch/wirth/ProjectOberon/index.html

Eric S. Raymond, in his guide "The Art of Unix Programming", mentions this principle as Rule of Silence: "When a program has nothing surprising to say, it should say nothing."

His statement probably related to command line applications, but it makes sense for a lot of cases.

What specifically are you looking forward to?

I love dmenu and similar tools, also I don't consider dmenu to be a dropdown element as part of an application UI (like dropdowns are in GUI apps).

> This is more about blending in among GUI tools, which is also important.

This is what I find difficult to understand, why is that important? And to whom?

It made sense 35 years ago when MS-DOS was shipped by default and you just had to make do.

Ah, I see, that's not what I meant (hence the 'TUIs are often tailored for advanced users' and 'the majority of GUIs prioritize user-friendly experiences for the general consumer' phrasing).

I agree there are also many GUIs tailored for professionals. Not sure if there are TUIs tailored for general consumers though.

> many want something they can click on [...] it's about reaching more people

To me, these reasons underscore the need for a genuine GUI, rather than a TUI that requires users to open a terminal just to have something clickable.

> Visual Studio (not Code), JetBrains, Photoshop, AutoCAD, Blender, every single tool for circuit simulation and FPGA programming would like a word with you.

I am not sure why you think my comment is in disagreement of that.

> The entire reason for lazygit to exist is to have a user-friendly experience for people who don't want to use the more complex and spartian git cli.

Same, I fully agree with that statement.

Do you have examples where this is the case? In my experience, they've always seemed mutually exclusive.

I prefer TUIs over GUIs primarily because TUIs are often tailored for advanced users — essentially, for professionals. In contrast, the majority of GUIs prioritize user-friendly experiences for the general consumer.

When a 'TUI' begins to incorporate features like mouse-clickable buttons, drop-down menus, scrollbars, windowed interfaces (as opposed to panes & separate screens), it gradually shifts away from its core identity. Eventually, it becomes a GUI operating within the limitations of a terminal.

Imagine something like lazygit with text-drawn buttons, drop downs and other TUI anti-patterns. Or even more extreme, without its keybindings and modality. It would miss the point entirely.

The D forum is also quite fast: https://forum.dlang.org/