Slashdot Mirror
OpenBSD's Alpha Support In Trouble
Nimrangul writes "Hours ago Theo de Raadt put out a call for an Alpha CS20, because as of last night OpenBSD no longer has one. The CS20 that died was a build machine and without it further support for the Alpha platform would be nearly impossible. If you have a C320 or other 1U Alpha machine that you would be willing to donate to the project, please respond to the discussion on the misc mailing list."
I wish them luck, but this has to give pause to anyone who wants to place a heavy bet on the continued availability of OpenBSD/Alpha -- if it can get wiped out because they can't get a specific piece of legacy hardware to fit Theo's rack!
What I'm listening to now on Pandora...
Last night something went wrong temperature wise in my machine room.
One of the build alphas is now dead.
I think Theo should also ask for aircon. I'm willing to help but 1U boxes tend to get hot, and I see no point in all chipping in for a new Alpha box to see it go pop again in 2 weeks time. Theo, tell us what went wrong and what you've done to fix it or what we can do to help you fix it. Then we can worry about replacing the hardware - otherwise I think it's probably just as well to ask for Alpha hardware and rackspace in a reliable colo as send the hardware back to the same place.
Try NetBSD... safe,straightforward,useful.
the netbsd-alpha list is pretty busy. I unsubscribed when I sold my alphas because I didn't need the mail traffic.
http://michaelsmith.id.au
Ummm, I may have a hard time reading, but I am pretty sure the story is talking about OpenBSD's Alpha support, not NetBSDs.
If you want to be sure something works properly you have to have the hardware it is supposed to be working on and test to see if it works on it.
NetBSD's setup does not actually make sure everything works, it makes sure it compiles under fake hardware.
That's how NetBSD's support for some platforms got so bad.
Why would NetBSD care?
This is OpenBSD.
Given the amount of equipment in Theo's server room and given the importance of this equipment to the project, why not construct a thermal shutdown device? How about a machine with a number of temperature probes around various points in the room, and when they all agree that the temperature is hot, they initiate shutdown+power-off procedures on the machines in the room? Now, I realize that some of the machines in the rack are older and may not have self-power-off abilities but it seems likely that enough of them could power down to make a difference.
That last sentence is wrong!
Native compiling on a [slow] platform doesn't test that "everything works" for that platform, just that the native compiler generates some code on a given model. This is especially relevant for platforms with a diverse range of hardware, including Alpha.
Cross-compiling on a fast platform reduces the turn-around time for providing software to test on slower platforms. (Why wait a week for a build to compile when you cross-compile in an hour?). The NetBSD cross-build framework offers other benefits such as allowing build an entire OS release (including install media) without requiring root privileges or fancy OS support such as loopback disk drivers. More details in my BSDCon 03 talk and build.sh paper.
Either build method does not remove the need for actually testing the resulting build on the variety of hardware available for a given platform. That is a separate and more important issue.
(Why do [AC] fanboys of some operating systems belittle functionality that their OS doesn't currently have, only to about-face and shout to the rooftops when they finally get it?)
The lack of actual compiling on your fringe hardware is why the support for it is so bad.
While it is true that it can be compiled faster on other hardware, that doesn't mean that the machine itself can compile it's own copy of the operating system.
If my machine cannot compile it's an operating system supposedly designed for it, there is a problem with the code and most likely how it works.
Cross compiling can be handy for speedy development, but not quality development. That's where the actual hardware comes in.
OpenBSD would be another matter entirely. It actually sees some signifignat use ...
Look at the keyboard in Theo's rack.
Anyone know where I can find a keyboard like that? Been looking for one just like it for months now.
I find it amusing that you'd suggest nobody uses NetBSD at a time when the front page of slashdot carries a link to a quaterly NetBSD report mentioning seven new developers, seven google "Summer of Code" projects and a number of donations from both individuals and corporations.
Just because we don't make such a song and dance over it doesn't mean we don't exist.
Hmm, your argument doesn't make sense for me.
At development stage, cross compiling makes the development really faster.
And at test phase, you can just compile the opreating system by the target system itself.
There is nothing which prevents this test phase in cross compilation
It seems you are just confusing the distinction of host system and target system.
It would probably get you the spotlight much better, maybe even as well as OpenBSD's music does.
Oh, the HFS+ rag,
It's such a drag.
We're coding all night,
Trying hard to get it right.
We're doing the HFS+,
Oh yeah the HFS+,
That crazy HFS+ rag!!!
Then maybe:
The zeroconf shuffle,
We're working on the double.
It's not quite so easy,
Making configuration easy.
Yeah, that zeroconf shuffle,
It's going ta save ya trouble,
So, we're doing the zeroconf shuffle!
Yeah!
Yeah, that would really get yas in the news.
I have a pc164 that's part of pool.ntp.org running as a stratum 1 ntp server. :-)
So that's at least one
Task reports may be boring (to some), but if nobody was using NetBSD, it's doubtful such reports would be issued.
I'm a big fan of the OpenBSD release songs (and OpenBSD itself is very nice), and it'd be great if NetBSD could offer something similar, but I don't really see it as a priority. I wouldn't really care if nobody ever heard of NetBSD, so long as it stayed as awesome as it is and I could keep using it.
But, apparently, it won't 'stay awesome' because they're drowning in a sea of red ink. Apparently their financial forecast has taken a sharp down-turn due to the fact that it turns out that their hosting provider doesn't accept foodstamps.
Surprisingly, this story has been relatively troll free.
there is also another kind besides the one the other guy mentioned. The one I have is called the "happy hacking" keyboard. They are great if you are in unix but you will have problems in doze, especially w/ microsoft apps like visual studio which use the Function keys a lot.
"If my machine cannot compile an operating system supposedly designed for it..." and it compiles fine on a cross compiler... there's a bug in GCC. NetBSD doesn't write GCC, so therefore the NetBSD cross compile framework is at fault. Ah I see, your logic makes perfect sense!
By your logic no current operating system could exist since the code would have to be initially cross compiled on some other architecture or written on the target from scratch in assembly. Good luck with that.
I use to be indecisive, but now I'm not so sure.
Which is, of course, absolute nonsense.
:)
FYI, NetBSD is mostly hosted by ISC, which doesn't charge hosting fees. NetBSD also runs its own colocated servers for all important servers and services. And for the financial situation in general, NetBSD is a volunteer Open Source product with no commercial backing. As such there is some need for money (mostly for running the above-mentioned machines to provide decent service), but so far this was covered fine by donations. Of course this shouldn't keep back any megacorporations lurking around here to donate a few gigabucks, I sure have some ideas on how to spend them.
In short, I don't know what you're pulling out of your nose here... maybe think again before posting if you have nothing important to say.
- Hubert
This isnt a troll, ( though it may sound like it ) but is the alpha port really that important now?
In its day alpha was the king of the hill, but in this day of dirt cheap ix86, is the alpha worth spending time on?
Sure if what you got works, dont toss it out.. But why beat it with a stick if its dead?
---- Booth was a patriot ----
I think he was trying to be funny, you know, cause the troll keeps talking about red ink and death and such.
I'm sick of following my dreams - I'm just going to ask them where they're going and hook up with them later.
I'm not some hardcore programmer, but I am going to agree with the obvious troll, if you're not compiling something native regularly then you're not ensuring that things work the way they should. Running a non-native programme will not be the same as running a native.
I just cannot make the assumption that cross compiling is infalible, the hardware is guaranteed to work the way the hardware will work and thus it makes more sense to me to do a native build of your systems.
Nice job, mod..
:/
Either you are very honest, or you know very well what "Troll" means..
maybe learn what compiling actually does.
it generates a bunch of bits into files... the bits are the same AS LONG AS THE COMPILER IS THE SAME on all systems.
It doesn't run any of these bits so it doesn't NEED to have the build target hardware.
What you're saying is akin to saying a text file written in vi on one system won't be the same as writing a text file on a different arch system.
If I can't smoke and swear I'm fucked.
Ran NetBSD for 3 years straight on an PC164 motherboard. Worked flawlessly until I moved and ditched it for a hardware router.
Only the State obtains its revenue by coercion. - Murray Rothbard
it generates a bunch of bits into files... the bits are the same AS LONG AS THE COMPILER IS THE SAME on all systems.
It doesn't run any of these bits so it doesn't NEED to have the build target hardware.
There was a recent thread about cross compiling on OpenbSD misc@. Perhaps this one summarize it nicely :
The same thing could be said of compiling on the same arch as target... a bug could cause the compilation to be buggy as well.
The SDK's for most consoles (and handhelds) are used with the compiler being on a different architecture then the targets. I'm not 100% sure but I don't think any console/handheld has a developer system of the same architecture as the target.
Now I know they compile different things then a computer, but the point is still valid.
If I can't smoke and swear I'm fucked.
Or is it a computer to you?
I'm sick of following my dreams - I'm just going to ask them where they're going and hook up with them later.
Sorry I meant handheld gaming systems like the PSP, DS, gameboy, etc.
Wasn't even thinking of cel phones or pdas.
However, I am surprised they develop code for it on the actual system.
If I can't smoke and swear I'm fucked.
I may be mistaken, but larger institutions (e.g. a government datacenter) will be using hardcore SMP with terrifying amounts of RAM and disk space, and yet OpenBSD doesn't yet scale up that high. They're forced to use Linux just because it 1) is free AND 2) scales really well, at the same time. This is not a popular combination.
FreeBSD >=5 is meant to be able to compete, but I haven't heard many success stories personally. I imagine OpenBSD with its giant lock definitely wouldn't be able to compete in terms of SMP, and without a journalling file system, the super-reliability needs might not be met.
To be really honest though, most exploits against Linux do still happen in the userland (not that the kernel doesn't have its exploits: they're just usually fixed sooner and are harder to exploit), and there you can just port fixes from OpenBSD or find more clever ways of tightening every last bolt. So the security of a super-scalable Linux datacenter could be practically comparable to an OpenBSD machine, without losing the value of your hardware (which is easily up in the millions).
But DragonFly BSD is hoping to be suitable for super-scalable tasks without compromising security, and while it's not quite there yet (at least in that its only native port is x86), it should be soon enough. If corporations and governments don't consider BSD *then*, there's really something wrong.
Of course this is all just servers. For desktops (that still need healthy security) the BSDs are more than suitable, yet their use is mysteriously overlooked. But I suppose if there's a Linux distribution which does decent QA without remaining in the dark ages, it could be not-too-bad itself.
Sam ty sig.
Yes, because a post answering an off-topic post must be even more off-topic than the post it answers. I hate Slashdot moderators.
Sam ty sig.
You don't understand it. The alpha code is not developed on another platform. Only the releases are compiled on another platform.
The same basic thing can be said about a lot of the older stuff..
But more often then not, price will win out. As i suggested..( or we wouldnt even be here talking about it )
Us PPC users are going to have to go thru the same thing soon im afraid. ( tho at least for a while we will still see those chips on servers and such )
---- Booth was a patriot ----
*BSD is dying. (Well, this machine did.)
:-)
Sorry. Someone had to say it.
OpenBSD Alpha is dying!
Believe me, if I started murdering people, there would be none of you left.
Ugh... "without a journalling file system, the super-reliability needs might not be met."
... it seems you don't have much experience or knowledge with OpenBSD or the "server scene" at all.
IIRC, there was a lot of discussion about OpenBSD's filesystem a while back.
Moral of the story: OpenBSD's scheme *guarantees* reliability, data integrity at ALL times, whereas journalled ext3 doesn't (or something)....
You've missed the whole point of OpenBSD...
1) It's code is obsessively analysed for flaws, and is made to be absolutely as correct as possible
2) As a result of this, it is RELIABLE
3) As a result of this, it is SECURE
Something which cannot be said of most Linux distros, not to the same degree of consistent quality.
It's all about choosing the right tool for the job. Forgive my arrogance if my assumption here is wrong, but from this: " and there you can just port fixes from OpenBSD"
Okay, I'm a retard... didn't see the original post you were answering to... stupid mods ;)
OpenBSD is just code. A GNU/Linux distro is just code. Exploits happen in code. If you want to fix an exploit, you fix code. Exploits can be removed by fixing code. I KNOW OpenBSD is hardcore in security, but if you want a Linux distro to be secure, you can go through and audit all of its code. OpenBSD is not looked over by the Gods of security: it's still code. It has had exploits.
My point is that a lot of servers do NOT need perfect OpenBSD-like security, they need realistic security against any reasonable chance of attack. They DO need high performance and scalability, which OpenBSD does not yet provide (don't even argue: giant lock SMP). If I was running a low-end secure server, it'd be OpenBSD (or more likely Net or DFly). If I was running a 128-way SMP machine, it would pretty much have to be Linux or maybe Solaris. It's a tough world but there are horses for courses. And that's all I'm saying, so don't assume I'm flaming OpenBSD's security.
Sam ty sig.
I realise (now) you were replying to an offtopic post... as I said elsewhere, I'm a retard.
The context I didn't realise your post was relating to was government stuff. Large NUMA/SSI/cluster setups. To which your sentiments are mostly justified.
However, I don't know about you, but I'm only doing less than 1000 lines of C++ refactored into ISO-C on my current project (long story). All the SLOC in apps that are used on a server... would number in the hojillions.
An admin simply doesn't have the time or patience to "audit" the source for the apps used in his/her own site. Much less understand the code they are looking at to be able to even begin auditing it.
How good are you at reading other's code? How well is all this userland code written?
Much less correct it, compile it, test/manage defect regressions, test and deploy modified versions. And commit the changes back. If an admin can do all this, what are they doing in an admin job? 99% of admins use off-the-shelf software, the most they might modify their apps is perhaps applying patches to source. Their programming is mostly in Perl/Python/Ruby/Bash/sh scripts.
Yes, you *could* find user-land OpenBSD patches and back-port them to a rusty Linux distro, but then your security can only at best match OpenBSD's.
Who is going to set up a team to audit code in a Linux distro? Who is going to decide *WHAT* to audit? Most distros are too diverse, OpenBSD gives you a very finite set of userland apps that have been audited... and it's the only feasible way, given their resources and the level of quality they commit to apps that they do look after.
When we start talking about "we could audit the Linux code instead", well we could in fact just take the Linux 2.2 kernel and patch it up to work with AMD64 couldn't we... but people don't because we have Linux 2.6.
I will admit most servers don't "need" OpenBSD-like security, but I'm sure you'll agree that most small to mid sized businesses where OSS usage is booming also don't need 128-way SMP boxen.
Perhaps the businesses I've looked after were too small, and tell the truth I've only ever used Linux for internal stuff (now looking into OpenBSD for some sites that want web exposure)... but even a basic "server" hardware package for sub-20 workstation sites spends a lot of time idling...
Anyway, it's late... I need to learn more OpenBSD...
All very valid points. I know there are some kernel-end security patches for Linux that give it some of OpenBSD's features, but I've had lousy luck keeping them running for more than a week, and they've usually been more for preventing local exploit than exploits in the kernel itself. I don't know if there are similar projects for a secure base-system userland though.
On a related note, DragonFly BSD is in the process of having its SMP bugs fixed, and afterwards will hopefully get wider testing on higher-end SMP systems. It's still only x86, but there are still numerous targets out there where it could be used in place of a Linux rig. And their devotion to security and good practices is impressive too: in my talks with devs via IRC, everything was about doing something cleanly, performantly, securely, and Rightly, not just getting it done fast to compete with somebody else.
Sam ty sig.
I got a 433au with eight gigs of raid and 128 ecc sdram