ELKS links broken

ELKS links broken

[Michael Sklaroff]

Hello Mr. Rhoads,

Thanks you for this excellent software project, but the download links
appear to be broken:

http://www.elks.ecs.soton.ac.uk/

http://core.nctritech.com/do/elks.tar.xz

http://www.cix.co.uk/~mayday/

ftp://ftp.ecs.soton.ac.uk/pub/elks/

Re: ELKS links broken

[Edoardo Liverani]

Hi Michael,
You are right, and those are not the only one broken or not updated links.
If you search "elks" or "linux 8086" on google the first links you get
are on sourceforge. And this is not updated cause this project have
recently been moved to github thanks to Jody Bruchon, the actual link
is https://github.com/jbruchon/elks .

I'd really like to help this project as I'm going to use it a little,
and I would enjoy to help hosting a website with updated links, to
generate updated and working precompiled images, istructions etc.
I have a shared hosting plan I can use, whom should I ask to get
current website sources and the permission to update a little and
re-publish them?
My question is particularly for @Jody cause he is the latest who
managed to maintain the project sources.

Best regards,
Edoardo

On Sat, Apr 5, 2014 at 3:12 AM, Michael Sklaroff <mdsklaroff@gmail.com> wrote:
> Hello Mr. Rhoads,
>
> Thanks you for this excellent software project, but the download links
> appear to be broken:
>
> http://www.elks.ecs.soton.ac.uk/
>
> http://core.nctritech.com/do/elks.tar.xz
>
> http://www.cix.co.uk/~mayday/
>
> ftp://ftp.ecs.soton.ac.uk/pub/elks/
> --
> To unsubscribe from this list: send the line "unsubscribe linux-8086" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Where does ELKS need to go? (was: ELKS links broken)

[Jody Bruchon]

On 4/18/2014 3:26 PM, Edoardo Liverani wrote:
> I'd really like to help this project as I'm going to use it a little,
> and I would enjoy to help hosting a website with updated links, to
> generate updated and working precompiled images, istructions etc.
> I have a shared hosting plan I can use, whom should I ask to get
> current website sources and the permission to update a little and
> re-publish them?
> My question is particularly for @Jody cause he is the latest who
> managed to maintain the project sources.

I am still here to maintain the project. Unfortunately, I've run into a 
couple of major issues with it that make its future questionable.

* I'll happily move and clean up the website to my own hosting if there 
is renewed interest in the project. I'll overhaul it while I'm at it.

* The compiler we use, bcc, suffers from some serious limitations and 
misbehavior. In particular, nothing can require more than 64K of code, 
including the kernel. The compiler needs some work or we need a new 
compiler. As I would like to see ELKS target other classic CPUs (65816, 
68000, maybe 6809, etc.) a compiler change may be the best option. The 
compiler is the biggest obstacle.

* What can/does ELKS offer compared to other small OSes such as NuttX?

* The hardware ELKS is made to work on is (to my limited knowledge) 
becoming rare. Quite a few 8086/88 machines have by now suffered 
capacitor failures that have rendered them inoperable and probably 
junked. Most PCs going in the garbage now are Pentium II/III/4 systems, 
all of which enjoy Linux compatibility and are far more capable under 
Linux than under ELKS, even if they only have 16MB of RAM.

* The "E" in ELKS means "embedded" and yet the only platform it was ever 
developed for was 8086/88 PCs and the Psion SIBO. The 808x target made 
more sense 10 years ago, but embedded and low-power computers today are 
dominated by 32-bit ARM and MIPS cores that happily run Linux (if they 
have enough RAM, that is.) What should ELKS be targeting today?

* The project has no active real-hardware testers to call upon. No one 
has real hardware AND time for the project AND wants to test changes. I 
personally have no 8086/80286 hardware but have a plethora of 
functioning Compaq 486 and Toshiba Pentium laptops, all of which have 
Linux on them. Without real hardware and a skilled, willing owner that 
can test ELKS on it, there can be no proper development. I can use 
emulators but they don't emulate the many various quirks and "just 
non-standard enough to piss you off" hardware of the early IBM PC era 
(I'm thinking about you, Tandy.)

* I have a TRS-80 CoCo and an Apple IIgs. Maybe we should port ELKS to 
those. ;-)

I would like to hear what anyone reading thinks. Please reply either to 
me OR the ELKS list since I (obviously) subscribe to it and prefer not 
to receive duplicate messages.

-Jody

Re: Where does ELKS need to go? (was: ELKS links broken)

[Edoardo Liverani]

Hi Jody,
I see all of your points, and I was just going to write down the
reason of my renewed interest in this project. It's just vintage
and/or nostalgic and it's not really a business but it's just for
hobby. But there are many pieces of software today made just for
hobby, so I don't blame myself for this.

> * The project has no active real-hardware testers to call upon. No one has
> real hardware AND time for the project AND wants to test changes
Actually I still own a very nice and working Olivetti M24, on which I
managed to test ELKS a bunch of years ago, and on which I'm managing
to put an IDE controller with an 8Gb microdrive (first tests
succeeded), which make really easy testing the . I also tested MINIX
2.0.3 on this one, it's nice, but I think not nicer and expandable as
ELKS is...
I have different ISA bus network cards, two (original) 20Mb MFM hard
drives, an EPP controller with a parallel port iomega ZIP 100Mb
(already slowly working with DOS), and I'm still trying to collect
more vintage/homemade hardware to put to work together.

> * What can/does ELKS offer compared to other small OSes such as NuttX?
Does NuttX run on 8086? ...

> * The compiler we use, bcc, suffers from some serious limitations and
> misbehavior. In particular, nothing can require more than 64K of code,
> including the kernel. The compiler needs some work or we need a new
> compiler.
I was missing this one. I see this is a big limit, though I thought
that bcc was a good and working compiler, and still I found it on
modern gentoo repository, ready to work.
What about (I'm just guessing, I really don't know it) the MINIX
compiler? I saw it working directly on my 8086!
Moreover I wonder what effort would require to improve bcc to avoid that limit.
In my experience I also saw DOS executables much bigger than 64K still
running on the 8086, what can we learn from them? Maybe from freedos?
["MINIX compiler" -> http://tack.sourceforge.net/about.html seems really nice]

> * The "E" in ELKS means "embedded" and yet the only platform it was ever
> developed for was 8086/88 PCs and the Psion SIBO. The 808x target made more
> sense 10 years ago [...] What should ELKS be targeting today?
[...]
> As I would like to see ELKS target other classic CPUs (65816,
> 68000, maybe 6809, etc.)
[...]
> * I have a TRS-80 CoCo and an Apple IIgs. Maybe we should port ELKS to
> those. ;-)
Well, I think that would be great: the big advantage of linux is that
it can run an be ported to many 32/64 bit architectures. We can made
ELKS working on many different 8/16 bit vintage computers, as I said,
not for real business but for hobbyist purposes. I also can't see the
real sense of the "E", at this point.

> Most PCs going in the garbage now are Pentium II/III/4 systems [...]

This project mission, as I see it, could well be to show to the world
how a good code on a very old pc could still get the same results as
many modern software full of garbage and overhead.
Today a basic linux kernel is at least 3Mb compressed, and requires
256Mb of ram to work properly with various bash shells, init scripts,
python, high level interpreted code, and so on (I'm thinking of
Raspberry-Pi). To show it's possible to achieve the same or equivalent
results with many-hundreds-times less hardware resources is a quite
impressive and very educational message to send to this increasingly
rapid growing [tech] world.

I'd like to transform my M24 to a full working (small) web server, I
think I can achieve this goal also with DOS or MINIX, but I think it
would be quite boring. I think ELKS still has a great potential and
its style is more similar to linux, and I really like it.

I hope I has been verbose enough and I look forward to hear what
others think about this.

Best regards,
Edoardo


On Fri, Apr 18, 2014 at 10:03 PM, Jody Bruchon <jody@jodybruchon.com> wrote:
> On 4/18/2014 3:26 PM, Edoardo Liverani wrote:
>>
>> I'd really like to help this project as I'm going to use it a little,
>> and I would enjoy to help hosting a website with updated links, to
>> generate updated and working precompiled images, istructions etc.
>> I have a shared hosting plan I can use, whom should I ask to get
>> current website sources and the permission to update a little and
>> re-publish them?
>> My question is particularly for @Jody cause he is the latest who
>> managed to maintain the project sources.
>
>
> I am still here to maintain the project. Unfortunately, I've run into a
> couple of major issues with it that make its future questionable.
>
> * I'll happily move and clean up the website to my own hosting if there is
> renewed interest in the project. I'll overhaul it while I'm at it.
>
> * The compiler we use, bcc, suffers from some serious limitations and
> misbehavior. In particular, nothing can require more than 64K of code,
> including the kernel. The compiler needs some work or we need a new
> compiler. As I would like to see ELKS target other classic CPUs (65816,
> 68000, maybe 6809, etc.) a compiler change may be the best option. The
> compiler is the biggest obstacle.
>
> * What can/does ELKS offer compared to other small OSes such as NuttX?
>
> * The hardware ELKS is made to work on is (to my limited knowledge) becoming
> rare. Quite a few 8086/88 machines have by now suffered capacitor failures
> that have rendered them inoperable and probably junked. Most PCs going in
> the garbage now are Pentium II/III/4 systems, all of which enjoy Linux
> compatibility and are far more capable under Linux than under ELKS, even if
> they only have 16MB of RAM.
>
> * The "E" in ELKS means "embedded" and yet the only platform it was ever
> developed for was 8086/88 PCs and the Psion SIBO. The 808x target made more
> sense 10 years ago, but embedded and low-power computers today are dominated
> by 32-bit ARM and MIPS cores that happily run Linux (if they have enough
> RAM, that is.) What should ELKS be targeting today?
>
> * The project has no active real-hardware testers to call upon. No one has
> real hardware AND time for the project AND wants to test changes. I
> personally have no 8086/80286 hardware but have a plethora of functioning
> Compaq 486 and Toshiba Pentium laptops, all of which have Linux on them.
> Without real hardware and a skilled, willing owner that can test ELKS on it,
> there can be no proper development. I can use emulators but they don't
> emulate the many various quirks and "just non-standard enough to piss you
> off" hardware of the early IBM PC era (I'm thinking about you, Tandy.)
>
> * I have a TRS-80 CoCo and an Apple IIgs. Maybe we should port ELKS to
> those. ;-)
>
> I would like to hear what anyone reading thinks. Please reply either to me
> OR the ELKS list since I (obviously) subscribe to it and prefer not to
> receive duplicate messages.
>
> -Jody

Re: Where does ELKS need to go?

[Harley Laue]

The TL;DR version of my reply below: the project likely needs to 
diversify into other platforms.

On 04/18/14 15:03, Jody Bruchon wrote:
> On 4/18/2014 3:26 PM, Edoardo Liverani wrote:
>> I'd really like to help this project as I'm going to use it a little,
>> and I would enjoy to help hosting a website with updated links, to
>> generate updated and working precompiled images, istructions etc.
>> I have a shared hosting plan I can use, whom should I ask to get
>> current website sources and the permission to update a little and
>> re-publish them?
>> My question is particularly for @Jody cause he is the latest who
>> managed to maintain the project sources.
>
> I am still here to maintain the project. Unfortunately, I've run into 
> a couple of major issues with it that make its future questionable.
>
> * I'll happily move and clean up the website to my own hosting if 
> there is renewed interest in the project. I'll overhaul it while I'm 
> at it.
>
> * The compiler we use, bcc, suffers from some serious limitations and 
> misbehavior. In particular, nothing can require more than 64K of code, 
> including the kernel. The compiler needs some work or we need a new 
> compiler. As I would like to see ELKS target other classic CPUs 
> (65816, 68000, maybe 6809, etc.) a compiler change may be the best 
> option. The compiler is the biggest obstacle.
I'm pretty sure it's been mentioned in the past, but SDCC might be an 
option (though, I don't think there is a code generator for 8086-80286). 
Edoardo's suggestion of TACK might be a good fit as well. I've had some 
experience with SDCC, but I haven't ever tried TACK. I will say, SDCC 
has a fairly dedicated community behind it and the project is still 
quite active. TACK, however, doesn't seem to have had many commits in 
the last few years.

In any case, it'd be a good idea to avoid compiler specific pieces of 
code as much as possible. Otherwise, it could be a BCC situation all 
over again (being stuck with a more-or-less dead compiler.) Obviously, 
for something like a kernel, it's nearly impossible, but most of that 
could be provided via headers and/or pulled in conditionally.

> * What can/does ELKS offer compared to other small OSes such as NuttX?
Running more than one process (I'm assuming at least.) IIRC, NuttX 
compiles the kernel into the application to run the single application 
on the hardware.

> * The hardware ELKS is made to work on is (to my limited knowledge) 
> becoming rare. Quite a few 8086/88 machines have by now suffered 
> capacitor failures that have rendered them inoperable and probably 
> junked. Most PCs going in the garbage now are Pentium II/III/4 
> systems, all of which enjoy Linux compatibility and are far more 
> capable under Linux than under ELKS, even if they only have 16MB of RAM.
>
> * The "E" in ELKS means "embedded" and yet the only platform it was 
> ever developed for was 8086/88 PCs and the Psion SIBO. The 808x target 
> made more sense 10 years ago, but embedded and low-power computers 
> today are dominated by 32-bit ARM and MIPS cores that happily run 
> Linux (if they have enough RAM, that is.) What should ELKS be 
> targeting today?
Might be kind of cool to see it running on other 8 & 16 bit processors. 
Not that it would be terribly practical (is anyone looking at this 
project /really/ that concerned with that though?), but an 8-bit AVR or 
16-bit MSP430 might be interesting target(s). In this case, it would be 
good to really try to appeal to the hobbiest and build a mini computer 
with the chip. Most all of these will need more RAM, USB (might be 
tricky), and a method to display video output. Audio would be a plus as 
well. This would obviously be a large to very large undertaking (porting 
the codebase alone would be challenging), but I think it /could/ really 
spark some interest in the project again.

> * The project has no active real-hardware testers to call upon. No one 
> has real hardware AND time for the project AND wants to test changes. 
> I personally have no 8086/80286 hardware but have a plethora of 
> functioning Compaq 486 and Toshiba Pentium laptops, all of which have 
> Linux on them. Without real hardware and a skilled, willing owner that 
> can test ELKS on it, there can be no proper development. I can use 
> emulators but they don't emulate the many various quirks and "just 
> non-standard enough to piss you off" hardware of the early IBM PC era 
> (I'm thinking about you, Tandy.)
I /really/ need to get my Tandy 1000TX (a 286 with a 20M harddrive) up 
and going. The power button, AFAIK, the only thing that doesn't work (it 
wore out and doesn't click into place anymore.) It's one of those easily 
fixable things that I just haven't bothered to do. It's also one of 
those, too many projects, not enough time.

> * I have a TRS-80 CoCo and an Apple IIgs. Maybe we should port ELKS to 
> those. ;-)
>
> I would like to hear what anyone reading thinks. Please reply either 
> to me OR the ELKS list since I (obviously) subscribe to it and prefer 
> not to receive duplicate messages.
>
> -Jody
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-8086" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Where does ELKS need to go? (was: ELKS links broken)

[Chad]

The world's changed a lot since 1995 (almost half my life ago?  dang.)
 when I started playing with ELKS.  The Raspberry Pi and Beaglebone
Black are both much more powerful than any desktop, old or new, I
could possibly buy then, and so much cheaper!

Also, UNIX v6 is now truly free and has been ported to x86-32.

If I were to start today, I would probably look at a Cortex M3
microcontroller, which has very limited memory, but quite a bit of CPU
power relative to an 8088.  (But I probably would have taken up a
different project altogether, probably a usable lightweight Linux
distro/userspace for Pentium III's or some such.  But probably I'd
tilt a completely different windmill altogether.)

The solutions leading to getting something that looks vaguely UNIXy
working on an M3/M4 might be quite interesting in general, I suspect a
new C compiler/runtime with memory guarding built in would be needed.
And even with the overhead of run-time checking - or even executing
bytecode - it could still be faster than an 8088!

I'll have to think about this... there *is* an answer to "Where does
ELKS fit into the 2014 world?" but I don't have it yet.

On Fri, Apr 18, 2014 at 1:03 PM, Jody Bruchon <jody@jodybruchon.com> wrote:
> On 4/18/2014 3:26 PM, Edoardo Liverani wrote:
>>
>> I'd really like to help this project as I'm going to use it a little,
>> and I would enjoy to help hosting a website with updated links, to
>> generate updated and working precompiled images, istructions etc.
>> I have a shared hosting plan I can use, whom should I ask to get
>> current website sources and the permission to update a little and
>> re-publish them?
>> My question is particularly for @Jody cause he is the latest who
>> managed to maintain the project sources.
>
>
> I am still here to maintain the project. Unfortunately, I've run into a
> couple of major issues with it that make its future questionable.
>
> * I'll happily move and clean up the website to my own hosting if there is
> renewed interest in the project. I'll overhaul it while I'm at it.
>
> * The compiler we use, bcc, suffers from some serious limitations and
> misbehavior. In particular, nothing can require more than 64K of code,
> including the kernel. The compiler needs some work or we need a new
> compiler. As I would like to see ELKS target other classic CPUs (65816,
> 68000, maybe 6809, etc.) a compiler change may be the best option. The
> compiler is the biggest obstacle.
>
> * What can/does ELKS offer compared to other small OSes such as NuttX?
>
> * The hardware ELKS is made to work on is (to my limited knowledge) becoming
> rare. Quite a few 8086/88 machines have by now suffered capacitor failures
> that have rendered them inoperable and probably junked. Most PCs going in
> the garbage now are Pentium II/III/4 systems, all of which enjoy Linux
> compatibility and are far more capable under Linux than under ELKS, even if
> they only have 16MB of RAM.
>
> * The "E" in ELKS means "embedded" and yet the only platform it was ever
> developed for was 8086/88 PCs and the Psion SIBO. The 808x target made more
> sense 10 years ago, but embedded and low-power computers today are dominated
> by 32-bit ARM and MIPS cores that happily run Linux (if they have enough
> RAM, that is.) What should ELKS be targeting today?
>
> * The project has no active real-hardware testers to call upon. No one has
> real hardware AND time for the project AND wants to test changes. I
> personally have no 8086/80286 hardware but have a plethora of functioning
> Compaq 486 and Toshiba Pentium laptops, all of which have Linux on them.
> Without real hardware and a skilled, willing owner that can test ELKS on it,
> there can be no proper development. I can use emulators but they don't
> emulate the many various quirks and "just non-standard enough to piss you
> off" hardware of the early IBM PC era (I'm thinking about you, Tandy.)
>
> * I have a TRS-80 CoCo and an Apple IIgs. Maybe we should port ELKS to
> those. ;-)
>
> I would like to hear what anyone reading thinks. Please reply either to me
> OR the ELKS list since I (obviously) subscribe to it and prefer not to
> receive duplicate messages.
>
> -Jody
> --
> To unsubscribe from this list: send the line "unsubscribe linux-8086" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Where does ELKS need to go?

[Royce Williams]

> On 04/18/14 15:03, Jody Bruchon wrote:

>> * The project has no active real-hardware testers to call upon. No one has real hardware AND time for the project AND wants to test changes. I personally have no 8086/80286 hardware but have a plethora of functioning Compaq 486 and Toshiba Pentium laptops, all of which have Linux on them. Without real hardware and a skilled, willing owner that can test ELKS on it, there can be no proper development. I can use emulators but they don't emulate the many various quirks and "just non-standard enough to piss you off" hardware of the early IBM PC era (I'm thinking about you, Tandy.)

I have a Compaq Deskpro 8086 (7.14 MHz) with a DTC-5150 MFM
controller, a 10M Winchester drive, a single 360K floppy drive, 640K
of RAM, and a 3Com 10base2 NIC (will have to check what model it is).

I am not a programmer, but I would *love* to test.  At times, the code
has seemed to be in a state where testing would be hard.  I haven't
kept track of the status of an installer, but that would really help
me be able to test more often.  Generally speaking, prioritizing a
minimum baseline of "installability" would really help more people be
able to test -- by reducing the friction and startup cost of testing.

Royce

Re: Where does ELKS need to go?

[Jody Lee Bruchon]

On April 19, 2014 2:28:44 PM EDT, Royce Williams <royce@tycho.org> wrote:
>Generally speaking, prioritizing a
>minimum baseline of "installability" would really help more people be
>able to test -- by reducing the friction and startup cost of testing.

You are right, and I think I can make that happen. Let me put my nose to the grindstone for a while and see if I can get together something that will make ELKS installable and bootable from a hard drive with less difficulty. That won't be a huge amount of work and will definitely close a big gap that has plagued ELKS from the start.

-Jody

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Re: Where does ELKS need to go?

[Royce Williams]

On Sat, Apr 19, 2014 at 10:33 AM, Jody Lee Bruchon <jody@jodybruchon.com> wrote:
> On April 19, 2014 2:28:44 PM EDT, Royce Williams <royce@tycho.org> wrote:
>>Generally speaking, prioritizing a
>>minimum baseline of "installability" would really help more people be
>>able to test -- by reducing the friction and startup cost of testing.
>
> You are right, and I think I can make that happen. Let me put my nose to the grindstone for a while and see if I can get together something that will make ELKS installable and bootable from a hard drive with less difficulty. That won't be a huge amount of work and will definitely close a big gap that has plagued ELKS from the start.

Fantastic!  I'm really looking forward to testing.  I hope that there
will be a 360K floppy install option. :-)

Another angle for encouraging participation (I've been a bit out of
touch with the project, so forgive the elementary questions) ... where
is the current main site?  Is it the GitHub page?  Wherever it is, I
think it shouldn't take long to get all of the other/older resources
out there to clearly point to wherever the main site is now.  Any
older docs that still have value should be replicated and unified at
that central location.

I'm not a programmer, but I could at least help to consolidate
documentation, to free up developer resources to do actual
development.  I have Mediawiki experience and can sling basic HTML.

Royce

Re: Where does ELKS need to go? (was: ELKS links broken)

[Royce Williams]

On Sat, Apr 19, 2014 at 10:07 AM, Chad <chad.page@gmail.com> wrote:
> I'll have to think about this... there *is* an answer to "Where does
> ELKS fit into the 2014 world?" but I don't have it yet.

Thinking pie-in-the-sky .... I think that using it to teach elegant OS
programming under resource constraints would be a great niche.  It's a
lost art, but one that has many "teachable moments" built in.

If the code is easy to read, and commented in a way that eases people
into the concepts, and plays nice on 8086 emulators (which ones?),
then it could serve both the retro/collector PC community and the
programming community.

Royce

Re: Where does ELKS need to go? (was: ELKS links broken)

[Jody Bruchon]

>Thinking pie-in-the-sky .... I think that using it to teach elegant OS
>programming under resource constraints would be a great niche.  It's a
>lost art, but one that has many "teachable moments" built in.

I think this is a good niche, but it will require that ELKS diversify beyond the 8086. I see the low-end 32-bit Intel platforms as a good target to begin with; while one can build a nice small Linux for use on a 486, Pentium, or even a VIA C3 or Transmeta Crusoe, such systems are grossly underpowered and somewhat memory-starved for modern Linux, glibc, X.org, gcc, and so on.

These systems are still relatively easy to run into and are regularly discarded. I have no working 16-bit PC-compatible hardware, but I have a closet slam full of 486 through P3 desktops and laptops. 

It would be fantastic for ELKS to run on these platforms. I don't see the 8086/286 as a viable target anymore. To be a "teachable" platform, people need to be able to use it without scraping up rare vintage hardware. Linux abandoned 386 support somewhat recently due to the nasty batch of workarounds required to keep it working, and I think ELKS must follow suit in its own way.

I would like to have a kernel that can build and run on everything from 8-bit to 32-bit, with or without an MMU, and taking advantage of platform specific features where possible. Unfortunately, once again the problem comes back to the compiler; 8-bit processors tend to be very poor compiler targets with limited ability for position-independent code and often require bank switching to reach extra memory, 16-bit processors tend to have ugly segmented memory models, and finding a good compiler that targets even a fraction of them is no easy task; never mind generating quality code!

So we come back to the original problem: we either need a compiler or a change of target...

Re: Where does ELKS need to go?

[Edoardo Liverani]

> Fantastic!  I'm really looking forward to testing.  I hope that there
> will be a 360K floppy install option. :-)
A really nice option would be something bootable from dos, like (or
maybe exactly) MINIX's boot.com
As soon as I get an Image compiled and working, I can put an eye on this.

> Another angle for encouraging participation (I've been a bit out of
> touch with the project, so forgive the elementary questions) ... where
> is the current main site?  Is it the GitHub page?
The current GitHub repository is at https://github.com/jbruchon/elks
By the way, there is a good source for this mailing list archive:
http://news.gmane.org/gmane.linux.ports.x8086 as you can see, the
second-last topic is "ELKS moved to GitHub".

Thank you,
Edoardo


On Sat, Apr 19, 2014 at 10:38 PM, Royce Williams <royce@tycho.org> wrote:
> On Sat, Apr 19, 2014 at 10:33 AM, Jody Lee Bruchon <jody@jodybruchon.com> wrote:
>> On April 19, 2014 2:28:44 PM EDT, Royce Williams <royce@tycho.org> wrote:
>>>Generally speaking, prioritizing a
>>>minimum baseline of "installability" would really help more people be
>>>able to test -- by reducing the friction and startup cost of testing.
>>
>> You are right, and I think I can make that happen. Let me put my nose to the grindstone for a while and see if I can get together something that will make ELKS installable and bootable from a hard drive with less difficulty. That won't be a huge amount of work and will definitely close a big gap that has plagued ELKS from the start.
>
> Fantastic!  I'm really looking forward to testing.  I hope that there
> will be a 360K floppy install option. :-)
>
> Another angle for encouraging participation (I've been a bit out of
> touch with the project, so forgive the elementary questions) ... where
> is the current main site?  Is it the GitHub page?  Wherever it is, I
> think it shouldn't take long to get all of the other/older resources
> out there to clearly point to wherever the main site is now.  Any
> older docs that still have value should be replicated and unified at
> that central location.
>
> I'm not a programmer, but I could at least help to consolidate
> documentation, to free up developer resources to do actual
> development.  I have Mediawiki experience and can sling basic HTML.
>
> Royce
> --
> To unsubscribe from this list: send the line "unsubscribe linux-8086" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Where does ELKS need to go?

[David Given]

[-- Attachment #1: Type: text/plain, Size: 2219 bytes --]

On 4/19/14, 5:45 PM, Harley Laue wrote:
[...]
> I'm pretty sure it's been mentioned in the past, but SDCC might be an
> option (though, I don't think there is a code generator for 8086-80286).
> Edoardo's suggestion of TACK might be a good fit as well. I've had some
> experience with SDCC, but I haven't ever tried TACK. I will say, SDCC
> has a fairly dedicated community behind it and the project is still
> quite active. TACK, however, doesn't seem to have had many commits in
> the last few years.

I'm the maintainer for TACK. It's actually had some development recently
--- and from people who aren't me, too! But unfortunately the design is
rather hostile to RISC architectures. But it's got decent C89 support
and a reasonable 8086 code generator, and it does have the big advantage
over bcc or pcc in that it's a complete toolchain --- it's got a libc,
an assembler and a linker in it, so it can be made to spit out binaries
with no external dependencies.

Adding a new target to TACK is a bit specialist but relatively easy.
Ping me if there's interest.

[...]
>> * What can/does ELKS offer compared to other small OSes such as NuttX?
> Running more than one process (I'm assuming at least.) IIRC, NuttX
> compiles the kernel into the application to run the single application
> on the hardware.

ELKS' big feature is that it's got a userland. Unfortunately I'm not
sure this is particularly useful these days, particularly as the way it
works is strongly dependent on having an MMU (the 8086's segmentation
counts as an MMU here). I doubt whether ELKS could be easily ported to a
non-MMU system. (How do you relocate a running process, for example?)

One option is to turn ELKS into a Unix emulation layer on top of NuttX,
but that would mean giving up a lot of what makes ELKS a Unix. And I'm
afraid that even for the 8086, ELKS has been superceded by Minix 2,
which is a lot more mature and robust than ELKS is.

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│
│ "You cannot truly appreciate _Atlas Shrugged_ until you have read it
│ in the original Klingon." --- Sea Wasp on r.a.sf.w


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 876 bytes --]