Needless to say that, even *if* there's an exploit for say, the webserver, out there: nobody's going to write shellcode for m68k.
For the same reason, Miod Vallat of OpenBSD fame runs his website on a VAX, and the BSI is said to still use BS/2000 somewhere. Even if not unbreakable, nobody's going to be able to use it;-) At least not your average 08/15 skriptkiddie.
Ah, thanks for the additional background. Yes, a pointer to the problems would probably be appreciated by the ARAnyM developers.
The d-i will not work right now, not with the normal mirrors at least, due to debootstrap being unable to cope with needing to pull packages from *two* distributions (unstable and unreleased), we think. We're working on it.
GCC 1.42 is fine (we run that on BSDi BSD/OS 3.1 as well, and RT compiled it on Minix-vmd since the shipped GCC 1.40 was broken); mksh is amazingly portable.
Do come over to the channel though;) We've got a few tricks.
IIRC, that wasn't it: it did find the root filesystem but was hardcoded to single user and securelevel -1 (I should note that this is the same kernel as was used for the installation).
But thanks for the offer anyway;-)
Since I can't find an eMail in the archives, I assume I only asked in IRC:( but I did the installation attempt at a conference, so...
Ask Atari-Frosch in #atari-home on OFTC for details, it's her computer, and she can power it on and look. (I think Linux failed due to too few ST-RAM for the kernel to fit. It's rather fat nowadays...)
I'm not good with details on Amiga, but I think the procedure is:
You boot some sort of Kickstart/Workbench, then run an AmigaOS program which is the Linux bootloader and pass it the kernel and, if needed, the initrd from the AmigaOS filesystem, it will load them and make them usable, then jump into Linux. From then onwards, that one will be the OS in charge, making ext4 available etc.
Sadly, no kexec yet. Having to copy out the kernel instead of being able to load it directly from ext4 (or whatever you choose) would be cool.
AFAIHH some of the emulation projects have made available Free (as in Freedom) ROMs for TOS (EmuTOS) and Kickstart, which contain enough code to run this without needing the proprietary Amiga stuff. But, like I said, I'm nowhere near knowledgeable about this part of those architectures, plus I mostly worked on (emulated and a few real) Ataris, not Amigas, while doing this. (And even there, I did as few as possible on the "native" side.)
Right, but I recently tried to install NetBSD/atari on AtariFrosch's box, and the installer died on itself. I, having BSD experience, managed to still install it by manually untarring the sets, running MAKEDEV, etc. but the kernel seems to have hardcoded booting into securelevel -1 and single user, so the system doesn't come up afterwards without some manual effort on each boot.
No NetBSD® person I asked could help, and the mailing list was dead as well.
Granted, the software works, but it's less refined. (That being said, while Wouter built a debian-installer image, nobody has tested it yet, and installing sid is always chancy due to its moving nature. But debootstrap, edit fstab, get a kernel and boot into it works.)
By the way, if you get AMIX running and with an ANSI C compiler, join the IRC channel #!/bin/mksh (yes, that's really its name) on Freenode, so we can port mksh to it;-)
cbmuser already issued an Intent To Package FS-UAE to Debian, which makes use of WinUAE's "accurate emulation".
I believe that you should be able to use wouter's d-i build from http://people.debian.org/~wouter/d-i/ to install an m68k system from unstable (with the usual caveats, i.e. installing or debootstrapping unstable does not always work). Note that the build is still "fresh" and nobody has tested it yet, so a failure would not mean an emulation problem.
Once FS-UAE is in Debian, I'll likely publish a disc image for starters like https://wiki.debian.org/Aranym/Quick for the emulated Atari. (Today, I'll make updated.tar.gz archives of a debootstrap result, which helps people already running etch-m68k or sarge (the image you linked is Debian 3.1 = sarge) to quickly install a fresh system, or at least the user space part.)
Watch the debian-68k@lists.d.o mailing list, and/or the Debian Wiki, for progress.
Last time I looked, qemu-system-m68k lacked MMU support. Someone recently said qemu-user-m68k was usable, but that does syscall level translation (I wonder what they do about the TLS and atomic-cmpxchg syscalls that are recent-m68k specific) and thus doesn't suffice.
Finding bugs in Debian, gcc, eglibc, the Linux kernel, by running it on minority systems is a decent outcome of this, Iâ(TM)d say.
The purpose of having bragging rights that mksh works on all platforms, no matter what obscure, is personal, so you canâ(TM)t measure relevance anyway. Iâ(TM)ve even done DEC ULTRIX and Haiku successfully. Oh, and Plan 9â¦
Besides, it was a nice project to learn about how Debian works;-)
You should learn to think outside of the box. What makes you think reviving ancient hardware ever was the purpose?
Besides this, I think the other replies already said everything needed.
Actually, I got KDE 4.8 working (to prove my patches against gcc-4.6 and qt4-x11 were correct). As long as you don't start KDEPIM (Kontact), it's actually decent fast (in tightvncserver):
Funnily enough, a sole GTK+ application (xchat) in a light-weight window manager (IceWM, otherwise much faster than KDE) was slower.
Of course, once I started Kontact, all bets were off, but then, whenever I do that on the company desktop at work (where we're forced to use it for Groupware - the calendar you see is my actual account at work, sans a few sensitive information) even a modern x86 machine gets slow;)
Not just Debian. Another two persons interested in porting mksh to anything possible and then some, as well as I, are trying to get an A/UX box running.
Also, whatâ(TM)s the leading GNU/Linux distribution on cris (ETRAX 100)? Debian doesnâ(TM)t support that⦠(also, I dab in klibc and dietlibc a bit, and the formerâ(TM)s got cris support code that warrants testing.)
Right, but we are doing this âoethe Debian wayâ, that is, running a native compilation and package generation in clean throw-away chroots. Debian package generation is not just compilation, itâ(TM)s a bunch of other stuff (dependency management, shared library management, etc.) and, personally *and* from my experience with the BSDs and FreeWRT, I am of the opinion that cross-compiling is only good for initially bootstrapping a port.
Besides, natively compiling forced us to fix lots of bugs in the kernel, eglibc and gcc, and backport other stuff to gcc, and to eat our own dogfood.
My goal with this was *not* just to have a system running Linux/m68k, but to have the process of auto-building packages working. (If you research, youâ(TM)ll find out that Iâ(TM)m a die-hard x86 and GW-BASIC fan, so I have no history with m68k other than eyeing them strangely for having the wrong endianness.) Also, I learned a lot of how Debian works in the process;-)
The latter approach is the better one in the long term.
You are expected to learn any programming language to actually use by yourself. The university gives you the basics, a broad overview, and the tools you need to learn these.
It is also a common mis-conception that youâ(TM)ll be employed immediately after finishing university. No, really not. University does not prepare for the workplace. You need more real-life experience than that, which is why universities (donâ(TM)t know about America, but over here they do) require at least one internship be passed before the diploma can be achieved. You will learn real-life work skills there, and (in case of a programming job) get real-life programming experience, which is dif- ferent from merely learning a programming language.
Trust me if I say that, with some shell languages such as mksh, you can both _script_ and _program_ in shell, such huge is the difference. Most never see the latter niveau.
Iâ(TM)d suggest you use the university time to _really_ get to know the basics of as many languages as you can â" including functional and other âoeweirdâ languages. Gwydion Dylan, Haskell, LISP, you name it. Then, do your assignments in various languages for play; youâ(TM)ll find out which ones you like/dislike and which ones are better/worse suited for the task at hand. Bonus points (to you only) if you do some of the assignments in two languages (probably using *different* algorithms â" tailor the algorithm to the language used, not to the theory related to the assignment, as academics want to make you).
Note I know both the academic world and that of âoecraftmanshipâ, Iâ(TM)ve seen both sides.
I first wondered IF I want to actually read about it then I said what the hey, lets look at it, know your enemy and all that.
All I get is an IBM Notice:
Our apologies... The page you requested cannot be displayed
Suggested actions
If you are looking for IBM Systems or Grid computing content on developerWorks, that content is no longer available. We suggest that you visit the following links for related content: IBM Systems, Systems, servers, and storage, or IBM Grid computing. If you typed the address, make sure the spelling is correct. Note: Most addresses are also case sensitive. If you clicked on a link, there may be a problem with that link. You can use "Get assistance" below. To navigate the IBM developerWorks Web site, start from IBM developerWorks. Use the search box at the top of this page. Or return to the previous page.
Get assistance
To tell us about a broken link, go to the IBM developerWorks Feedback page.
... didn't the Perry Rhodan series predict that in the early 1960s already?
AFAIK this comes up every few years, as does the painless tooth handling (sorry, English is not my native language), but it's the same as with the 3 Litres per 100 km cars, or the car engines made from ceramics, which didn't make it because they don't make enough income (e.g. the ceramics because they're too stable and don't break apart soon, like in Asterix & Obelix "we need less durable stones").
FreeBSD(TM) doesn't even have a booth planned, and none of the other BSDs (NetBSD(TM) didn't even plan to come, like last year) has got even as few as one table.
FOSDEM this year is, sadly, going to suck.
But then, my #1 favourite US American is going to visit a free country, let's have some beer you can't get over there due to some age limit:)
OpenBSD's Matthieu Herrb is already working on that.
I'll try to feed them back to XFree86(TM), though. MirOS will keep to use it until fd.org is ready, and probably years after that, leaving fd.o an optional package only.
> Our preferred license is the same license as the > program being documented. If you write a GPLed > program, have GPLed documentation. If you write a > MIT-licensed program, have MIT-licensed > documentation.
This goes for _most_ projects except the FSF. The BSDs share this, the OSI afaik too.
On the GFDL: http://home.twcny.rr.com/nerode/neroden/fdl .html
Slashdot Mirror
Sorry, confused that. He built it on Linux 0.13 or something like that; Minix-vmd has ACK that works fine. On 386BSD 0.0 even GCC 1.39 was usable ;-)
But we're getting off-topic slowly... though that's probably normal.
Needless to say that, even *if* there's an exploit for say, the webserver, out there: nobody's going to write shellcode for m68k.
For the same reason, Miod Vallat of OpenBSD fame runs his website on a VAX, and the BSI is said to still use BS/2000 somewhere. Even if not unbreakable, nobody's going to be able to use it ;-) At least not your average 08/15 skriptkiddie.
Ah, thanks for the additional background. Yes, a pointer to the problems would probably be appreciated by the ARAnyM developers.
The d-i will not work right now, not with the normal mirrors at least, due to debootstrap being unable to cope with needing to pull packages from *two* distributions (unstable and unreleased), we think. We're working on it.
https://wiki.debian.org/M68k/Installing in the meantime has an ext2fs image you can use / boot into, and kernels.
I've asked Atari-Frosch to power on the machine and then comment here, so we will have boot messages.
Thanks for the help!
Mhm. Can the kernel image be changed, like with config(8) -ef /bsd on MirBSD/OpenBSD, to not do that?
I think something in /etc/rc drops me to single user when INSECURE is set, but itâ(TM)s been quite an amount of months, so I do not remember precisely.
Cool, thanks!
GCC 1.42 is fine (we run that on BSDi BSD/OS 3.1 as well, and RT compiled it on Minix-vmd since the shipped GCC 1.40 was broken); mksh is amazingly portable.
Do come over to the channel though ;) We've got a few tricks.
IIRC, that wasn't it: it did find the root filesystem but was hardcoded to single user and securelevel -1 (I should note that this is the same kernel as was used for the installation).
But thanks for the offer anyway ;-)
Since I can't find an eMail in the archives, I assume I only asked in IRC :( but I did the installation attempt at a conference, so...
Ask Atari-Frosch in #atari-home on OFTC for details, it's her computer, and she can power it on and look. (I think Linux failed due to too few ST-RAM for the kernel to fit. It's rather fat nowadays...)
I'm not good with details on Amiga, but I think the procedure is:
You boot some sort of Kickstart/Workbench, then run an AmigaOS program which is the Linux bootloader and pass it the kernel and, if needed, the initrd from the AmigaOS filesystem, it will load them and make them usable, then jump into Linux. From then onwards, that one will be the OS in charge, making ext4 available etc.
Sadly, no kexec yet. Having to copy out the kernel instead of being able to load it directly from ext4 (or whatever you choose) would be cool.
AFAIHH some of the emulation projects have made available Free (as in Freedom) ROMs for TOS (EmuTOS) and Kickstart, which contain enough code to run this without needing the proprietary Amiga stuff. But, like I said, I'm nowhere near knowledgeable about this part of those architectures, plus I mostly worked on (emulated and a few real) Ataris, not Amigas, while doing this. (And even there, I did as few as possible on the "native" side.)
Right, but I recently tried to install NetBSD/atari on AtariFrosch's box, and the installer died on itself. I, having BSD experience, managed to still install it by manually untarring the sets, running MAKEDEV, etc. but the kernel seems to have hardcoded booting into securelevel -1 and single user, so the system doesn't come up afterwards without some manual effort on each boot.
No NetBSD® person I asked could help, and the mailing list was dead as well.
Granted, the software works, but it's less refined. (That being said, while Wouter built a debian-installer image, nobody has tested it yet, and installing sid is always chancy due to its moving nature. But debootstrap, edit fstab, get a kernel and boot into it works.)
By the way, if you get AMIX running and with an ANSI C compiler, join the IRC channel #!/bin/mksh (yes, that's really its name) on Freenode, so we can port mksh to it ;-)
If you are interested, that is.
cbmuser already issued an Intent To Package FS-UAE to Debian, which makes use of WinUAE's "accurate emulation".
I believe that you should be able to use wouter's d-i build from http://people.debian.org/~wouter/d-i/ to install an m68k system from unstable (with the usual caveats, i.e. installing or debootstrapping unstable does not always work). Note that the build is still "fresh" and nobody has tested it yet, so a failure would not mean an emulation problem.
Once FS-UAE is in Debian, I'll likely publish a disc image for starters like https://wiki.debian.org/Aranym/Quick for the emulated Atari. (Today, I'll make updated .tar.gz archives of a debootstrap result, which helps people already running etch-m68k or sarge (the image you linked is Debian 3.1 = sarge) to quickly install a fresh system, or at least the user space part.)
Watch the debian-68k@lists.d.o mailing list, and/or the Debian Wiki, for progress.
Last time I looked, qemu-system-m68k lacked MMU support.
Someone recently said qemu-user-m68k was usable, but that does syscall level translation (I wonder what they do about the TLS and atomic-cmpxchg syscalls that are recent-m68k specific) and thus doesn't suffice.
Finding bugs in Debian, gcc, eglibc, the Linux kernel, by running it on minority systems is a decent outcome of this, Iâ(TM)d say.
The purpose of having bragging rights that mksh works on all platforms, no matter what obscure, is personal, so you canâ(TM)t measure relevance anyway. Iâ(TM)ve even done DEC ULTRIX and Haiku successfully. Oh, and Plan 9â¦
Besides, it was a nice project to learn about how Debian works ;-)
You should learn to think outside of the box. What makes you think reviving ancient hardware ever was the purpose?
Besides this, I think the other replies already said everything needed.
Actually, I got KDE 4.8 working (to prove my patches against gcc-4.6 and qt4-x11 were correct). As long as you don't start KDEPIM (Kontact), it's actually decent fast (in tightvncserver):
http://oi47.tinypic.com/2058vue.jpg
Funnily enough, a sole GTK+ application (xchat) in a light-weight window manager (IceWM, otherwise much faster than KDE) was slower.
Of course, once I started Kontact, all bets were off, but then, whenever I do that on the company desktop at work (where we're forced to use it for Groupware - the calendar you see is my actual account at work, sans a few sensitive information) even a modern x86 machine gets slow ;)
The motto in the IRC channel (#debian-68k on OFTC) was actually "Go away Santa. We're hacking code."
Not just Debian. Another two persons interested in porting mksh to anything possible and then some, as well as I, are trying to get an A/UX box running.
Also, whatâ(TM)s the leading GNU/Linux distribution on cris (ETRAX 100)? Debian doesnâ(TM)t support that⦠(also, I dab in klibc and dietlibc a bit, and the formerâ(TM)s got cris support code that warrants testing.)
Right, but we are doing this âoethe Debian wayâ, that is, running a native compilation and package generation in clean throw-away chroots. Debian package generation is not just compilation, itâ(TM)s a bunch of other stuff (dependency management, shared library management, etc.) and, personally *and* from my experience with the BSDs and FreeWRT, I am of the opinion that cross-compiling is only good for initially bootstrapping a port.
Besides, natively compiling forced us to fix lots of bugs in the kernel, eglibc and gcc, and backport other stuff to gcc, and to eat our own dogfood.
My goal with this was *not* just to have a system running Linux/m68k, but to have the process of auto-building packages working. (If you research, youâ(TM)ll find out that Iâ(TM)m a die-hard x86 and GW-BASIC fan, so I have no history with m68k other than eyeing them strangely for having the wrong endianness.) Also, I learned a lot of how Debian works in the process ;-)
The latter approach is the better one in the long term.
You are expected to learn any programming language to actually use
by yourself. The university gives you the basics, a broad overview,
and the tools you need to learn these.
It is also a common mis-conception that youâ(TM)ll be employed immediately
after finishing university. No, really not. University does not prepare
for the workplace. You need more real-life experience than that, which
is why universities (donâ(TM)t know about America, but over here they do)
require at least one internship be passed before the diploma can be
achieved. You will learn real-life work skills there, and (in case of
a programming job) get real-life programming experience, which is dif-
ferent from merely learning a programming language.
Trust me if I say that, with some shell languages such as mksh, you
can both _script_ and _program_ in shell, such huge is the difference.
Most never see the latter niveau.
Iâ(TM)d suggest you use the university time to _really_ get to know the
basics of as many languages as you can â" including functional and
other âoeweirdâ languages. Gwydion Dylan, Haskell, LISP, you name it.
Then, do your assignments in various languages for play; youâ(TM)ll find
out which ones you like/dislike and which ones are better/worse suited
for the task at hand. Bonus points (to you only) if you do some of the
assignments in two languages (probably using *different* algorithms â"
tailor the algorithm to the language used, not to the theory related
to the assignment, as academics want to make you).
Note I know both the academic world and that of âoecraftmanshipâ, Iâ(TM)ve
seen both sides.
I first wondered IF I want to actually read about it
then I said what the hey, lets look at it, know your
enemy and all that.
All I get is an IBM Notice:
Our apologies...
The page you requested cannot be displayed
Suggested actions
If you are looking for IBM Systems or Grid computing content on developerWorks, that content is no longer available. We suggest that you visit the following links for related content: IBM Systems, Systems, servers, and storage, or IBM Grid computing.
If you typed the address, make sure the spelling is correct.
Note: Most addresses are also case sensitive.
If you clicked on a link, there may be a problem with that link. You can use "Get assistance" below.
To navigate the IBM developerWorks Web site, start from IBM developerWorks.
Use the search box at the top of this page.
Or return to the previous page.
Get assistance
To tell us about a broken link, go to the IBM developerWorks Feedback page.
404 Not Found
That's obvious :-)
IFU = Intel's Fucked Up
BSU = BullShit Unit
just kidding... a happy AMD user
... didn't the Perry Rhodan series predict that in
the early 1960s already?
AFAIK this comes up every few years, as does the
painless tooth handling (sorry, English is not my
native language), but it's the same as with the
3 Litres per 100 km cars, or the car engines made
from ceramics, which didn't make it because they
don't make enough income (e.g. the ceramics because
they're too stable and don't break apart soon, like
in Asterix & Obelix "we need less durable stones").
FreeBSD(TM) doesn't even have a booth planned, and none
:)
of the other BSDs (NetBSD(TM) didn't even plan to come,
like last year) has got even as few as one table.
FOSDEM this year is, sadly, going to suck.
But then, my #1 favourite US American is going to
visit a free country, let's have some beer you can't
get over there due to some age limit
OpenBSD's Matthieu Herrb is already working on
that.
I'll try to feed them back to XFree86(TM), though.
MirOS will keep to use it until fd.org is
ready, and probably years after that, leaving
fd.o an optional package only.
x.org doesn't have any reason to exist, for me.
Especially since PHP links against both OpenSSL
and GNU libreadline, if installed.
The binary created (even through dynamic linking)
is something I can use perfectly well, but it's
illegal to redistribute (by the GPL).
> Our preferred license is the same license as the
l .html
> program being documented. If you write a GPLed
> program, have GPLed documentation. If you write a
> MIT-licensed program, have MIT-licensed
> documentation.
This goes for _most_ projects except the FSF.
The BSDs share this, the OSI afaik too.
On the GFDL:
http://home.twcny.rr.com/nerode/neroden/fd