Tinyx – Resurrected Xvesa from the depths of Git history | Hacker News Reader

Tinyx – Resurrected Xvesa from the depths of Git history

github.com

Oh my, you've just brought up some amazing memories from my past time as systems administrator! I would setup SliTaz [1] on some ancient hardware and worked right out of the box with very little RAM. I have had so much fun using this distro!

Here's the link where you can read about xvesa support in SliTaz: https://doc.slitaz.org/en:guides:xorg-xvesa

[1] https://slitaz.org/en/

Damn, slitaz... That's a blast from the past. Right next to bb4win and openshell in my childhood OS explorations.

Indeed a blast from the past, well said @ang_cire!

> no xkb; it's bloat when console keymaps suffice

So on the pro side, that sounds like you could just configure your keyboard layout once and have it work everywhere, which would be nice. On the con side, I'm not aware of a way to switch console keymaps on the fly; setxkbmap lets me configure a hotkey that switches layouts instantly, which is really handy. Or am I misunderstanding the impact?

Ideally you'd have a programmable keyboard. That way it keeps the OS configuration down to a absolute minimum. It is just easier that way. Especially if you want to use multiple OSes and such things.

Well yes, ideally I would prefer to be able to implement things in firmware (especially chording), but since I mostly use laptops I'm a bit stuck. And yes, I can probably use things like keyd to work around it, but it seems a bit unreasonable to require that level of mucking around in order to switch keyboard layouts.

That'd be a non-starter to me. I switch between US and Norwegian layouts depending on which language I'm writing, and while I could "just" map the additional Norwegian characters to other combinations, I don't want to.

I came across this recently while looking at buildroot and tinycorelinux. I'm still working on it but tinyX+awesome is my target for a kind of minimum-viable-system. I love software that I can conceivably learn enough about to contribute to without giving up my life, and tinyX (and awesome) both tick those boxes.

As a broader observation, it is encouraging to see things like this on HN as my (perhaps flawed) assumption is that generally small software is efficient software. I for one have had enough of my UX standing still because of code sprawl, and I wish we could get back to a time when a few hundred MHz or less was enough for most things.

> I wish we could get back to a time when a few hundred MHz or less was enough for most things.

Modern display resolutions and color depths alone are responsible for a huge part of why that's no longer the case. And most people aren't interested in giving that up...

Sure I like nice hidpi antialiased, slightly shadowed buttons with translucency, but I kind of like pixel embracing UIs (nice pixel fonts with no AA are quite legible to me). I'm on and off on writing a tiny 4 colors desktop with simple remote abilities..

Not a fan of the license change.

Deliberately making the software less useful drains the preservation value the project would otherwise provide.

> Deliberately making the software less useful

Well, I'm sure you'll be happy to find that GPL3 does not make any software any less useful. It just means that if you want to extend the software, you must distribute source code with it. Any entity which finds this unacceptable doesn't deserve to be using this software anyway.

It becomes more useful because it encourages people to distribute source code that they may not have otherwise.

> if you want to extend the software, you must distribute source code with it

Incorrect. GPLv3 does not require source code distribution if you choose to only distribute your extensions to third parties that are under a current contract to you to operate or modify the work or any derivative thereof on your behalf and to destroy all copies of your extensions at the conclusion of the contracted operational and/or modification work.

I’m surprised that $1 modification contracts for GPLv3 works are uncommon. Open source isn’t free!

(I am not your lawyer, this is not legal advice.)

Isn't this how using GPL-ed code in commercial contexts work? You don't have to share sources with the outsiders if you don't ship the program to the outsiders - and your employees and contractors are bound by their contracts to share neither the proprietary extensions nor the resulting program with the outside world. Note that SaaS means you're not shipping backend software to users, which created a loophole that has a special GPL variant patching it.

altairprime's idea seems to be to sell the software to your users, but hire them as contractors to modify the gpl code so they can not redistribute it themselves.

So on perm saas where the on perm operators are technical hired for $1 so the software was never legally distributed to the company that hired the on perm saas service.

Seems dubious to me.

Specifically, it’s dubious because GPLv3 requires the third party’s modification and/or hosted operation to be exclusively on behalf of / for the client. A judge and/or jury would need to evaluate whether the license is legally valid in that jurisdiction, and whether an attempt to circumvent the spirit of the license through obligating a contracted third-party to use the code would regardless still comply. (For example, QA is permissible use, but what if QA has to be done at scale in a for-profit production environment by the contracted third party, etc.) I expect that a reasonable and demonstrated set of modifications and setting and enforcement milestones would both be essential to a determination in favor of it being permissible use — but of course I cannot guarantee this with certainty, lacking any prior judgments to refer to. (I am not your lawyer, this is not legal advice.)

If youre contracted to provide software to party A. If that software includes gpled parts you have to supply the source to them. That doesn't mean you have to supply the source to everyone.

Samsung or however could require proof that you'd actually bought one of their TVs before supplying the source. In practice they dont, but they could.

Red hat are now doing exactly this. Only red hat customers can get hold of the red hat source.

> I am not your lawyer, this is not legal advice.

I've quoted the one bit of your statement I agree with. You suggest an entirely artificial relationship to completely bypass the clear intention of the licence. To be blunt, that's a terrible suggestion.

I encourage you to reconcile your disagreement with my first paragraph, and GPL 3.0 section 2 paragraph 2. (I certainly respect your disagreement with my second paragraph, though!)

Okay to be fair, your first paragraph was spot on! It's an interesting but not widely discussed exception.

(I think the word "purpose" in said paragraph encapsulates why I strongly disagree with your conclusion on your second paragraph.)

Agreed: https://news.ycombinator.com/item?id=36500774

> It just means that if you want to extend the software, you must distribute source code with it.

It means a lot more than that. The most significant difference in my line of work is the anti-tivoization requirements. Essentially if you ship this software in a device, you must allow the user to change the software/firmware on that device. I do embedded Linux work for several different clients, and they are almost never OK with this. So I have to be careful to never use GPLv3 software.

Not that I agree completely with the OP. I love when I can customize the firmware on devices I get (that is almost a precondition for my purchasing it), and I wish more manufacturers were OK with it.

Please note that the GPLv2 has the requirement that users be able to modify and reinstall the GPLed software. "Tivoisation" isn't what Tivo actually did and both the GPLv2 and GPLv3 ban "Tivoisation" but allow what Tivo actually did. "Tivoisation" as it is popularly known refers to blocking the running of modified GPL code, while what Tivo actually did was block running their proprietary software (their UI etc) on top of modified GPL code (here Linux). Both GPL versions block the former while allowing the latter. At least according to Software Freedom Conservancy.

https://sfconservancy.org/blog/2021/mar/25/install-gplv2/ https://sfconservancy.org/blog/2021/jul/23/tivoization-and-t... https://events19.linuxfoundation.org/wp-content/uploads/2017...

A good point. For completeness though, I think that the way many modern embedded devices accept updates (arguably) skirts around the GPLv2 requirements. For instance many devices will only accept signed updates, or will only accept updates from a particular https server. The GPLv3 is much more explicit about these matters.

It is fine to require signed updates, as long as the user can get their own updates installed. Usually that involves enrolling a new signing key, signing the updates with the user key and allowing user-signed updates. The shim tool used by Linux distros for Secure Boot is designed to allow that even if the UEFI firmware isn't and some UEFI implementations may allow controlling the signing keys.

I expect that most of the cases you cite are simply outright GPL violations though.

Either this information is incorrect or a lot of companies have been getting away with violating this for decades with no consequences. Take for example, the Nintendo Switch. It contains GPL'ed software, which Nintendo makes available on their website (https://www.nintendo.co.jp/support/oss/), but they make absolutely no interface for the user to modify or replace any (GPL or not) code that was not provided by them. Lots of companies do this in fact... practically every modern car on the road is another example. And allowing them to have user-replaceable code would be a huge no-no for a variety of (potentially deadly) reasons. Same for medical devices.

Indeed, most companies violate this requirement and copyright holders of GPLed code generally don't have legal/economic resources needed to enforce the license.

There is a test case that will, if successful, allow all recipients of GPLed code to sue for GPL compliance, this will open up the possibility of enforcement to users too, which could potentially lead to class action GPL lawsuits.

https://sfconservancy.org/copyleft-compliance/vizio.html

On cars, read through the presentation above, it discusses GPLv3 in cars and how that could work. Basically, there is a lot of proprietary software on top of the GPLed software in cars. When you modify the GPLed software, the other software would stop working (or be removed), and so your car would stop driving until you replaced it. You would then need to write replacements, you could then drive on your own property, or get them certified by the relevant authorities for use on public roads.

https://events19.linuxfoundation.org/wp-content/uploads/2017...

> Essentially if you ship this software in a device, you must allow the user to change the software/firmware on that device.

This would have been useful to have for e.g. Android, where tech companies are trying to turn mobile phones into vehicles for their nonsense rather than devices under the user's control.

It's gotten to the point where I have to acquire devices with arbitrary R/W vulnerabilities just so I can patch the OS, flash my own AVB signing keys, re-generate vbmeta etc etc just to have a rooted device, but then I have one with an unpatchable arbitrary R/W vulnerability, so it's arguable how "secure" the result is...

Secure enough to watch netflix though, which is the real danger. https://xkcd.com/129

In what case would the license change impact anything? You want to make proprietary changes to the X server?

It could be significant in embedded devices due to the anti-tivoization requirements of the GPLv3.

This sounds beneficial rather than otherwise.

I feel like the historical culture of X development is permissive licenses and proprietary Unix vendors developing closed solutions on top. It was deliberately like that. So this feels like a departure.

The Unix Wars were a waste of time and money for everyone involved. By the time they realized it they were already dead. There's no reason to bring back that business model.

While that is the case and still is today, i remember Keith Packard (a prominent X developer) making various remarks over the year in his presentations on the negative side of having all these companies making their own private forks without contributing code back.

This is precisely what Tinyx is doing: A "private" fork in a license that would make it impossible to contribute code back to Xorg.

That is only if Xorg doesn't switch to GPLv3.

Though of course in that case (i.e. Xorg not switching) someone can fork Xorg, relicense it to GPLv3 and merge the TinyX code - so everyone gets their cake.

In practice however i doubt anyone would bother with any of the above (including Xorg wanting to merge any TinyX contributions).

I remember propietary accelerated X releases. That set X.org back almost for a decade.

It's not clear that they can change the license. For example in dix/dixfonts.c it says:

>Copyright (c) 1991, 1997 Digital Equipment Corporation, Maynard, Massachusetts. > >Permission is hereby granted, free of charge, to any person obtaining a copy >of this software and associated documentation files (the "Software"), to deal >in the Software without restriction, including without limitation the rights >to use, copy, modify, merge, publish, distribute, sublicense, and/or sell >copies of the Software. > >The above copyright notice and this permission notice shall be included in >all copies or substantial portions of the Software.

Given the various GPL theories of tainting linked code and that this requires specific permissions be included with the program, not sure they can put a GPL license on the overall resulting product.

> including without limitation the rights to ... sublicense ... the Software.

Sounds like they can distribute that code under the GPL, provided they include the notice (which is OK from the GPL PoV since it doesn't frustrate what the GPL provides). That particular code continues to be available under its original license. The whole is available under the GPL. Licenses are permission to do things that would otherwise be prohibited by copyright; there's no problem with having extra permission or multiple kinds of permission. What part do you think would be a problem?

The license on this file gives extremely broad permission to distribute with no requirements. The GPL has requirements if you are distributing it. These two licenses are not compatible.

Additionally, if they are starting with software under a particular license and modifying it, in a non clean room fashion, then the final product is a derivative of the original and the copyrights likely remain with the original rights holders.

This is nonsense.

> The GPL has requirements if you are distributing it.

The GPL gives you permission to distribute subject to certain requirements. Having extra permission is not a problem.

> Additionally, if they are starting with software under a particular license and modifying it, in a non clean room fashion, then the final product is a derivative of the original and the copyrights likely remain with the original rights holders.

All of the (nontrivial) contributors to the final project will hold some copyright interest in it. As long as all of them are granting the permission you need, that's not a problem.

> The license on this file gives extremely broad permission to distribute with no requirements. The GPL has requirements if you are distributing it. These two licenses are not compatible.

That's not how it works at all. You receive the file under a broad license, but can redistribute it under a more restrictive license. Anyone who receives that file under the GPL is subject to the GPL's obligations even if the file previously existed under another license, as long as they weren't actually granted that other license.

This is the entire foundation of "contact me for a less restrictive license"-type monetization schemes. It doesn't matter which licenses the file was ever licensed under, it matters which license was granted to you with the file.

That's not quite how it works, you can relicense stuff under GPL and your distribution and any changes you made are GPL'd but the original remains MIT.

https://writefreesoftware.org/learn/participate/derived-work...

https://writefreesoftware.org/learn/participate/copyright-ow...

If you need to be exempted from the GPL v3 requirements, then pay the license holders for a different license. If you offer them enough they will probably come to the table.

Meanwhile, everyone without that need will benefit from the protections that GPL v3 provide.

The README mentions this other project:

https://github.com/idunham/tinyxserver

which has an XServer.man file that mentions X11/MIT-like license, but otherwise doesn't state a license for the project as a whole.

Low-level VESA/VGA routines:

https://github.com/tinycorelinux/tinyx/tree/master/kdrive/ve...

Is this any relation to Nano-X? http://microwindows.org/

No.

TinyX is an XServer, it only talks to VESA compatible graphics hardware and provides an X11 interface. It's intended for PCs.

Nano-X is a graphics library that can talk to frame buffers, graphics hardware, or an XServer and can provide some level of X11 interface as well as a Win32 API. It's intended for embedded machines.

It's also provides a standalone graphics server, not just a library.

I used it for a bit 25 years ago when we were using it as the GUI for a Linux based tablet because X took too much memory...

Does it provide a graphics server in the absence of all the X11 foundation libs? TBH, I've only played with microwindows in DOS, OSX with XQuartz, and Linux with X11.

Yes. With the caveat that my knowledge of Nano-X is about 20 years out of date: It very specifically is not X, though the API is close to the Xlib API, and there's a shim that provides some X11 compatibility, and of course on the backend there's an X11 driver.

But it only requires a driver that can handle a minimum of reading/setting individual pixels and draw horizontal and vertical lines and manage the palette (of course if whatever you're drawing on supports more than that, you'll get far better performance if you implement e.g. blits).

We were using it without any shims, and had a very tiny GUI lib running directly against the Nano-X API, and contracted Opera to port their browser to it as well to use on our tablet.

It was a fun project, but way too early - the hardware we built was beautiful but so extremely constrained, leading to put a huge effort into shrinking everything. Never made it to mass production.

Interesting link!

If we look at this directory:

https://github.com/ghaerr/microwindows/tree/master/src/drive...

Most notably the source files that start with 'scr_', and of those most notably: scr_sdl2.c, scr_win32.c, scr_x11.c, scr_djvesa.c, scr_fb.c -- we see that this windowing system can apparently run on top of an existing windowing system, whether that system is SDL2, Win32, X11, VESA, Linux's framebuffer -- or several others.

Which makes it interesting and worthy of study...

Note that I am sure there are probably a whole lot of other windowing systems out there that also support these, let's call them "back-end" (for lack of better terminology) pre-existing windowing systems.

In other words, a windowing system -- on top of another windowing system...

Sort of like running X on top of Win32, or Win32 on top X...

But the posibilities of higher level and lower level windowing system are really unlimited -- mix and match, basically...

In conclusion -- excellent link!

Also works on DOS w/djgpp.

Sounds neat but wouldn't using DRM be better than fbdev nowadays? AFAIK (from having played around with DRM recently-ish and with fbdev years ago) it should be possible to abstract the "get a framebuffer" part (IIRC fbdev didn't have much of an API and all of it can be mapped to DRM).

I had more luck with KDrive for a minimal but functional X server (for an OS installer in my case).

If this worked under MirBSD it could resurrect some 386 and 486's.

Also, there's is a pocketchip-like computer based on a 486 sx I think.

http://www.mirbsd.org/

Reply on news.ycombinator.com