81–90 of 103 posts
Oh wow, I'm getting Amstrad craving all over again.
Mine is a 464 w/ DDI interface, 64KiB RAM expansion, SDcard based "floppy" drive, mouse, and RS232 serial port. Still only a green screen, though, and I've yet to make a ROM box.
Also see:
Earlier quoted context omitted.
Much of the bloat is from higher resolution graphics, and all the layers of mitigation of various security issues that comes with multitasking.
But orders of magnitude more bloat? I had full multitasking in the late 80's, on an Amiga 500 with 512K of RAM. There was no memory protection, but there was a GUI. I remember running Linux (kernel 1.0 and earlier) with X11, in 8 megs of RAM or less, back on an old 486. I could compile kernels. Running emacs was a bit painful, however. What we have today is more bloated than I could have possibly imagined 20 years ag…
Compiler bloat is definitely an issue. There has been a lot of work that goes into intermediate representations and all sorts of optimizations that results in very diminishing or no returns for many use cases.
Runtime bloat is a much bigger issue. You have multi-stage runtimes that have an interpreter, a bytecode compiler, and a JIT. Huge amounts of RAM use and very CPU intensive. This makes sense for webGL games, but totally pointless for the common case of running tracking adware on websites whose only real content is a page or two of text.
The main problem are applications with poorly written event loops and memory leaks. That is why modern computing feels bloated. Slightly better compiler output or another 5% improvement in JS runtimes cannot solve this problem. It is a type of induced demand - the more RAM and CPU you have, the more accessible computer programming becomes to people who have very little idea of what they are doing and how to do it properly.
Why does every OS screenshot (not from a big company) always have to have a few pictures of women in it? It's ridiculously unprofessional in my book.
Problem solved!
Nice to see GEOS referenced in this article - it also was the underpinning for the Atari ST line of computers that did well Europe and swung well above their weight. If only I could find an ST 1040 again to appreciate Revenge of the Mutant Camels on a machine that was as good at desktop publishing, animating, creating sprite based games and and making music.
If you're looking for an ST, they pop up from time to time on Goodwill's auction site.
Nice to see GEOS referenced in this article - it also was the underpinning for the Atari ST line of computers that did well Europe and swung well above their weight. If only I could find an ST 1040 again to appreciate Revenge of the Mutant Camels on a machine that was as good at desktop publishing, animating, creating sprite based games and and making music.
I thought the ST line was all about GEM. If you're looking for an ST, they pop up from time to time on Goodwill's auction site.
Earlier quoted context omitted.
I thought the ST line was all about GEM. If you're looking for an ST, they pop up from time to time on Goodwill's auction site.
I might be mistaken and it might be GEM. There was the base os and then another window manager it would go into.
Symbos is pretty cool but it's a crying shame that it's closed source. A lot of people in the z80 community don't understand the value of open source, but will give away binaries for free.
Earlier quoted context omitted.
> you just need PIC. Or a relocator. This can be a bit tricky but it's been done on many architectures.
Do you have any links/pointers to systems that did this?
https://en.wikipedia.org/wiki/Relocation_(computing)
If you have access to the symbol table it is an easy problem to solve, if you don't it can get quite difficult all the way to impossible if the original code makes use of tricks such as jumping into the middle of an instruction. But if the code is 'well behaved' then it can usually be done.
Many games used tricks like this to relocate themselves to memory that was otherwise not usable for programs, for instance to live in secondary screen space. This ensured the game would be wiped on reset. Crude but effective.
Earlier quoted context omitted.
MenuetOS also suffers this problem. The 64 bit version is closed-source/non-Free, but available free of charge. Great way to limit wider interest in the project, and they're not even making bank. They get to spite the people who'd want to fork the project, I guess. The D programming language also had this problem for a long time (closed-source/non-Free compiler backend), but thankfully no longer.
Tiny correction: the reference D compiler's source code was available, but its backend was not Free Software (it was non-redistributable). This was not by choice of its authors, but due to a historical IP/licensing snag. Today it is fully open-source.
Earlier quoted context omitted.
MenuetOS also suffers this problem. The 64 bit version is closed-source/non-Free, but available free of charge. Great way to limit wider interest in the project, and they're not even making bank. They get to spite the people who'd want to fork the project, I guess. The D programming language also had this problem for a long time (closed-source/non-Free compiler backend), but thankfully no longer.
Just because outsiders consider something a "problem" does not make it so. I find it odd to talk about someone else's baby like that.
That D's licensing issues are now gone, certainly benefits D.
Even if adoption isn't the goal, making it FOSS might still make good sense. Suppose the goals are novelty and technical achievement. More interest means more support in developing their novelty OS, no?