28-Mar-2024 14:34 GMT.
UNDER CONSTRUCTION
Anonymous, there are 9 items in your selection
[Web] What Matt Dillion (DICE, csh, etc...) have been up to.ANN.lu
Posted on 10-Oct-2003 04:35 GMT by 3seas (Edited on 2003-10-10 20:03:26 GMT by Christian Kemp)9 comments
View flat
View list
What has Matt Dillon of some Amiga Open Source programming been up to lately? Interesting read "Dragonfly BSD Forum logs now available: IRC log text based and IRC log html based. Yes he mentions the Amiga, several times..
What Matt Dillion (DICE, csh, etc...) have been up to. : Comment 1 of 9ANN.lu
Posted by Emeric SH on 10-Oct-2003 08:39 GMT
It doesn't seem employees sit idle at Genesi... Poor souls :]

Nice site as usual!
What Matt Dillion (DICE, csh, etc...) have been up to. : Comment 2 of 9ANN.lu
Posted by Emeric SH on 10-Oct-2003 08:51 GMT
Ooops... wrong thread? :]
What Matt Dillion (DICE, csh, etc...) have been up to. : Comment 3 of 9ANN.lu
Posted by Bodie on 10-Oct-2003 09:04 GMT
In reply to Comment 2 (Emeric SH):
lol emeric :)
What Matt Dillion (DICE, csh, etc...) have been up to. : Comment 4 of 9ANN.lu
Posted by Christophe Decanini on 10-Oct-2003 10:27 GMT
His name is Matt Dillon.
What Matt Dillion (DICE, csh, etc...) have been up to. : Comment 5 of 9ANN.lu
Posted by Anonymous on 10-Oct-2003 14:11 GMT
>What has Matt Dillion of some Amiga Open Source programming been up to lately?

hmmm...acting? *rofl* *scnr*
What Matt Dillion (DICE, csh, etc...) have been up to. : Comment 6 of 9ANN.lu
Posted by Joe "Floid" Kanowitz on 10-Oct-2003 15:57 GMT
Heh. I feel like a dork for the redundant badgering now, but I hope mine helped get "the point" across for those not steeped in the technical end.

Personally, while the kernel developments *should* stand for themselves, I see the whole thing as an opportunity for BSD to meet-and-beat Linux on the basics (choice of filesystems, ease of adding and maintaining driver support for the latest wunderperipherals) while leaving out the "kitchen sink."

Dillon's pragmatic, hence my inability to get a Fleecy-grade answer. (Feh, and I was curious to see what his 'ideal desktop' might be, just to get to know the guy. Chances are he's seen enough to want to stick with a command prompt.) His interest is "building it," and it has to stand on its merits to get the [driver | FS | UI | stuff-we-haven't-imagined-yet] guys to come.

(Not to misrepresent a lack of driver or FS support now; that's the open-source benefit of forking, and the existing hands are doing a very capable job of maintaining and merging support. I'm talking about the day when NVidia/ATI or GNOME Storage type folk might actually choose it as their primary *NIX.)
What Matt Dillion (DICE, csh, etc...) have been up to. : Comment 7 of 9ANN.lu
Posted by 3seas on 11-Oct-2003 12:22 GMT
What I found interesting is that Matt seems to also understand the value of the third user interface enough to make it second on the priority list. The first being underlying multi-system and CPU support (LWKT) that provides some inherent quality of the third user interface.Matts csh for the Amiga contains two commands that allow you to send and receive fromthe arexx port of applications, and without using AREXX.Matt also seems to understand that making userland more user friendly and less constrained is a good thing.Other Projects I've shown interest in is the GNU Hurd but Matt is right about the Mach Microkernel that Hurd was being written on, now the L4 microkernel.(to much complexity and even security issue on the Mach)There is AROS, and its a project I'll certainly continue watching and perhaps doing stuff with. But I've also projected AROS as a smart terminal on the Hurd in order to take advantage of the GNU software base.Now comes along DragonflyBSD where its to apparently contain recognition of the third user interface as well as to be open to GNU works.I looked into Matts freeBSD commit removal matter, and not only do I have no problem with his direction that caused the "trust" problem freeBAD "core" has with him, but cheer him on in what he is doing."...unwinding the giant lock..." hmmmm, what exactly did Matt mean by that?If this DragoflyBSD is to be and becomes what I am lead to believe.... Then it is likely to be better than the Hurd+AROS.. and certainly an OS for which I'll be interested in using the VIC on/in.
What Matt Dillion (DICE, csh, etc...) have been up to. : Comment 8 of 9ANN.lu
Posted by Joe "Floid" Kanowitz on 11-Oct-2003 19:25 GMT
In reply to Comment 7 (3seas):
3seas said,
> I looked into Matts freeBSD commit removal matter, and not only do I
> have no problem with his direction that caused the "trust" problem
> freeBAD "core" has with him, but cheer him on in what he is doing.

Um, sheesh. This isn't OpenBSD, nobody has a *reason* to have bad blood (or stoop to childish insults). FreeBSD has way too much invested in the 5 road to change course now, Matt was obviously unhappy with it, and the 'village elders' sent him packing to force him to build his own village.

This is how it's supposed to work.

> "...unwinding the giant lock..." hmmmm, what exactly did Matt mean by
> that?

Maybe he meant "unwinding the giant lock?"

In an SMP system, you basically have two options when dealing with concurrency (making sure things happen in the right order, and something else doesn't start happening before it.. um, can.. which tends to send the system panicking in flames). You can 'lock' - cause a function or whatever to preempt until completion - or find a way to handle it asynchronously.

FreeBSD 5 is all about going into things like device drivers that would normally just fall under the Giant Kernel Lock, and implementing "fine grained locking," where only the parts that really, really need to be locked do so. This is hella cool when it all works right (think the 'coolness' of OS4 - finally, "AmigaOS" from the legacy codebase on PPC), but it's a monumental effort, and all you end up with at the other end is the original codebase, plus fine-grained locking... Plus the competing? approaches to threading that may keep userland different from kernel, and different chunks of kernelland itself possibly using different approaches. (Raw SAs versus KSEs vs...)

DBSD restructures everything to a message-passing model that, if I understand it, offers a simplified approach to locking (messages create locks as fine-grained as the content of the 'message,' or avoid them if they can be handled async? Not sure how much I really know there; http://www.dragonflybsd.org/Goals/messaging.cgi may help someone savvier, though unless it's been edited, that code snippet is already stale), introduces the LWKT ideal, and promises to mirror the threading model as the One True Path in userland while making a lot of other handy tweaks.

So if 5 is [insert your favorite classic car here] with the cylinders bored out and superchargers strapped on, DragonFly is a gas-electric hybrid; a completely different approach that still preserves the advantages of its legacy.

(For purposes of this analogy, Linux is an ethanol-burning motorhome with a rotary. With a steam-engine powered by a light water reactor available as an option.)

> If this DragoflyBSD is to be and becomes what I am lead to believe....
> Then it is likely to be better than the Hurd+AROS.. and certainly an

Depends on your definition of 'better.' It's not going to be a 'pure' microkernel, but in so doing, it'll avoid the pitfalls of same, while approaching the benefits asymptotically.

On the other hand, FreeBSD 5 - when playing stable (in the sense of 'capable of gathering uptime without strange hiccups,' versus any organizational idea of 'stable') - will probably be able to wear the performance crown for a while, at least on certain configurations. DBSD is going to be what you want on a lab or rack full of [Durons | Athlon64s | >=0.8 GHz anything] when you can't be bothered with hassles. It's what you'll want on your desktop of similar power if you'd rather be getting work done. 5 is what you may still want on the highest of the high-end racks (where utmost performance is paramount), and ironically, on 'junk' hardware like my 2xP-II Intellistation, when wringing out every % of performance is perhaps worth the headache.

But the difference will be just that - a couple percent at the worst, with DBSD looking for elegant ways to approach and surpass - and as hardware scales, it'll be more and more worth the tradeoff if there's still a tradeoff to be made. (Meanwhile, by the time DBSD hits 1.0, 5 will have had time to unhose itself a little, perhaps finish growing portability onto PowerPC, and find other compelling reasons to keep existing. Can you tell I like both?)

Seriously, I like to think of 5 taking on Solaris (performance hack vs. performance hack), and DBSD taking on Linux ('real' architectural flexibility vs. organizational flexibility), or for that matter, "the world."

> OS for which I'll be interested in using the VIC on/in.

Um, okay. "VIC?"
What Matt Dillion (DICE, csh, etc...) have been up to. : Comment 9 of 9ANN.lu
Posted by 3seas on 13-Oct-2003 02:40 GMT
In reply to Comment 8 (Joe "Floid" Kanowitz):
Ok, a email exchange with Matt and I may be wrong about this user land messaging.
That it is lower level and really more for developers than the user. However, (and there was some miss understanding when I wrote "arexx port" as he understood that as a scripting languge), Matt did not rule out the possibility of implimenting some sort of arexx like scripting, but its not in the plans....

in csh there are two commands rxrec and rxsend that can communicate with any arexx port, and without arexx running... I'm not sure if Matt put that in or if it was done later by someone else.

anyways, I wrote back to clairify what I ment when I said "arexx port" and suggested its the ports that are importent and this means applications, devices and libraries need an easy way to add such a port to them.

so to explain, this would be (is on teh Amiga) the third primary user interface. (the first two are the cli and Gui) .... the third being the side door port.

With such a port in applications devices, libraries, these things will have a vocabulary set unique to each of them.

The VIC is a tool that provides a way to organize, document and automate the use of these vocabularies. sorta providing the user with some programming abilities for their own use.

Where scripting languages having such a port can as well be used thru or by the VIC and what all the VIC can connect to.

freshmeat.net/projects/victor1
Anonymous, there are 9 items in your selection
Back to Top