Contributed by jolan on from the cache-aliasing-sucks dept.
(Comments are closed)
OpenBSD Journal
Contributed by jolan on from the cache-aliasing-sucks dept.
(Comments are closed)
Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]
By Nate (65.94.99.88) on
Comments
By Anonymous Coward (72.154.176.103) on
Comments
By Anonymous Coward (156.34.219.151) on
'mg' is the emacs-type text editor included with OpenBSD. Just for fun, it includes an assortment of ... uh .. sayings. Check it out:
http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/mg/theo.c
Comments
By Anonymous Coward (128.171.90.200) on
( M-x means press the <ESC> key, release it, then press x. )
By Venture37 (217.22.88.123) venture37 # hotmail com on www.geeklan.co.uk
>
> 'mg' is the emacs-type text editor included with OpenBSD. Just for fun, it includes an assortment of ... uh .. sayings. Check it out:
>
> http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/mg/theo.c
"in your world, you would have a checklist of 50 fucking workarounds just to make a coffee."
Brilliant!!
rofl! :)
By Nate (65.94.99.88) on
http://en.wikiquote.org/wiki/Theo_de_Raadt has others.
By gwyllion (134.58.253.130) on
Comments
By Jason Wright (65.202.219.66) jason@openbsd.org on http://www.thought.net/jason
Part of what we were looking at in FreeBSD was the locore <-> C boundary and their implementations of flushing, etc. Those bits are processor specific, but, frankly, a ton more readable than OpenBSD's locore (inherited from NetBSD).
By Anonymous Coward (66.11.66.41) on
Comments
By Chas (147.154.235.52) on
OpenBSD leaves none behind - the ports for VAX and 68k Macs are still supported. Instead of bailing on the Alpha, it was just moved to GCC 3. This has two benefits: a) the user community can re-task old hardware if they wish (like an Aviion), and b) it catches bugs in the source.
Comments
By Anonymous Coward (70.27.15.123) on
This is all very irrelivant. Sparc64 is already supported. They are just adding support for a particularly buggy, broken, worthless chipset. This is like suddenly adding MCA support to i386, not like maintaining support for mac68k.
Comments
By Chas (147.154.235.51) on
> This is all very irrelivant. Sparc64 is already supported. They are just adding support for a particularly buggy, broken, worthless chipset. This is like suddenly adding MCA support to i386, not like maintaining support for mac68k.
I wouldn't agree - see the previous story on the m88k-based Aviion. There are undoubtedly more us3-based systems in the field than working Data General Aviion workstations. If an Aviion can draw the interest of a developer, then the us3 should be irresistable.
Comments
By Anonymous Coward (66.11.66.41) on
>
> I wouldn't agree - see the previous story on the m88k-based Aviion. There are undoubtedly more us3-based systems in the field than working Data General Aviion workstations. If an Aviion can draw the interest of a developer, then the us3 should be irresistable.
Aviion didn't intentionally try to stop openbsd from running on their hardware. Miod had actual docs for it. There are no docs still for the shitty, buggy, broken schizo chipset. And the interest developers did have way back when, was because it would be the fastest arch with proper NX support. AMD64 now has that distinction.
By Anonymous Coward (216.175.250.42) on
Or, y'know, you can bitch about someone doing something interesting and useful some more.
Comments
By Anonymous Coward (70.27.15.123) on
>
> Or, y'know, you can bitch about someone doing something interesting and useful some more.
Nobody is bitching, its a question. And no, bugs are not fixed by adding support for another shitty, broken chipset. Or, y'know, you can just make up stupid nonsense since you don't have an answer to the question.
Comments
By Anonymous Coward (216.175.250.42) on
Christ, from the vitriol, you'd think that the devs were pouring sugar in your gas tank as they coded.
Comments
By Anonymous Coward (66.11.66.41) on
>
> Christ, from the vitriol, you'd think that the devs were pouring sugar in your gas tank as they coded.
What vitriol? Read it again, this time without your bizzare desire to see it as something its not. Its a simple question. Given that the schizo chipset is undocumented, horribly buggy and broken, is produced by a company openbsd dev's hate, and is no longer interesting like it used to be since amd64 is now a much faster platform with real NX support, why bother spending the time and effort to add support for it?
Comments
By Nate (65.94.99.88) on
Cause, it's there.
By Anonymous Coward (128.171.90.200) on
Comments
By Anonymous Coward (128.171.90.200) on
By Anonymous Coward (70.27.15.123) on
But yet you can't name any reasons? Its just "I like crappy machines for no reason"?
Comments
By Chas (147.154.235.51) on
> But yet you can't name any reasons? Its just "I like crappy machines for no reason"?
There is at least one extra security feature available on Ultrasparc. I'm fuzzy on the details, but it has to do with the chip's register windows and the OS saving them off when the depth of function calls becomes too large. This extra security is not available on any i386 variant.
There was a previous writeup on this on undeadly. You will also find no lack of i386 architecture criticism from the main developers on the mailing lists and in interviews.
Comments
By Anonymous Coward (216.175.250.42) on
The paper that originated it (and details the OpenBSD implementation) can be found here:
[ps] [pdf] [html]
By Anonymous Coward (128.171.90.200) on
because I didn't name any doesn't mean I don't have any, just like just because you have one doesn't mean you have to be one.
Most non-x86 derivatives, have a more sane design all round ( UltraSparcIII cache aliasing not withstanding. )
Comments
By tedu (69.12.168.114) on
yeah, requiring strict alignment is such a great feature. makes working with byte streams so much more convenient.
not to mention all the time incoherent caches have saved software developers.
Comments
By Anonymous Coward (128.171.90.200) on
incoherent caches ?
are you honestly trying to tell me that x86 are the only platforms that do not suffer from incoherant caches ? I find that hard to believe
By Anonymous Coward (70.27.15.123) on
Maybe you should read the cvs commit messages. There is nothing sane about the hardware in question. Its braindead, apparently buggy, and undocumented. AMD64 ain't perfect, but its a hell of a lot better than the ultrasparc 3 crap.
Comments
By Anonymous Coward (128.171.90.200) on
By Jason Wright (65.202.219.66) jason@openbsd.org on http://www.thought.net/jason
Why not? I like Sun gear. I like Sun processors. I like the challenge of making stuff work... even if it's buggy and poorly documented. It fits into my view of OpenBSD, and if it fits yours, great. If not, oh well.