Because it sucks by having hardware that cant handle memory above 1G, which means either it goes, or your 1+ G machine becomes 1G machine. (or you start doing the ISA-bus style memory bouncing for all network drivers since any device can DMA to/from the same mbufs that the bce later should handle)
So either a massive rewrite of all other network drivers, OR, kill the driver for the broken hardware that pretends to be useful but isnt.
Then again, some of us dont use the randomized ipv6 addresses but rather get to choose the numbers ourselves (especially for servers which you may need to enter ips for), and in those cases, you can get away with having to remember five "octets" instead of four, like 2001:abc:def:123:: which means it will be possible to learn for you to use when the DNS is unusable.
Then again, the bug came up while failing to compile xulrunner, so it wasnt hunting for stupid 30+ years old code noone uses, but running a compile of something from this side of the millenium that in the end pointed to this bug.
And if you follow the replies on that link you get to see why server admins don't like clients that grab more resources than necessary. It works as long as you are the only one doing it, but when everyone starts using segmented downloads, everyone loses. And you not only go back to as it was before, you also manage to waste more than the same number of poeple would have before, if they would stick to using one connection per download.
There has been discussions on the openoffice distribution lists about this too. Not everyone is convinced that having each client opens loads and loads of connections per download is the desired solution in the end.
The windows drivers I've seen on laptops ask their users to enter what country they are in, meaning it is extremly simple to choose a "better" country for you broadcasting rules if the current one doesn't allow what you like. How come the FCC dont raid those manufactorers?
I think you're mixing stuff up. The "blob" part is like the Nvidia binary drivers for X11. What Theo is asking for is to be allowed to re-distribute the firmwares for the chips, so that you can use the network card for installs, for instance. If you are required to go through a webpage and click Yes before you can use your network card, then it's pretty much useless for installs unless you already had another network card in there already.
Then, on top of this, he seems to want the specs for the API used to talk to this firmware-driven hardware, so that they can write a driver of their own. Big difference there. * Firmware - please allow us to redistribute verbatim copies of it. * API - docs in order to write free drivers.
These are two things needed in order to get those intel cards going. Since the firmware in one way or another already is available on the net or on the CD in windows-format, there really shouldn't have to be such a problem to allow redistribution of it. For the API's, everyones guess as to why you'd need to keep them secret is as good as theirs.
As he states somewhere, not getting these two parts makes the card unusable anyhow, so there's nothing to lose really.
It's not like the whole linux world would fall apart if there was some more string functions which would not go ape on weird inputs. I know strl*() isn't a magic bullet to prevent all kinds of badness, but they really can't be worse than the same functions without bounds checking.
Why aren't someone already doing a SSH of their own then? Apart from the proof-of-concept-type ssh clients out there (good or bad) there is *nothing* to stop anyone from taking the same ssh1-code and reimplementing all the goodies OpenBSD got in there. Or write a GPL'ed own ssh for the linux crowds. The specs are there, the protocol isn't secret.
It's not like it isn't possible, its just that building up that kind of trust seems harder than you'd first imagine. These guys have made it, others may not.
One of the reasons for threading an app even on single-cpu systems would be that you dont have to do async IO for one. You can have the emailthread talk net all the "same" as the browser tries to save that 100M pr0n archive you just downloaded. So while the main thread waits for something, the others can run, but usually (when the mozilla developers test it? =) two things never happen exactly at the same time, but on those darned smp machines, it sometimes does. Then weird stuff breaks and I get another adressbook. (on next start it always says: "Hey, can't read it, I called the old one abook-24234234.bak-something and invented a new one")
http://people.su.se/~jj/FreeSBIE-1.0-i386.iso.torr ent
Re:Maybe time to drop this "securitier than thou"
on
Remotely Crash OpenBSD
·
· Score: 1
There is a difference between: "He should do X" and "I think he shoudl do X to achieve Y". Especially when Y isn't on the goals.html page. Yes, more users would seem logical, but it's not one of the goals. Reread it and you'll see.
Re:Maybe time to drop this "securitier than thou"
on
Remotely Crash OpenBSD
·
· Score: 1
The response from TdR shouldn't be Ok, tell me *WHY* it should be any different. And when you have figured out one or more reasons why it should be anything different, match those reason to the list here: http://www.openbsd.org/goals.html If you get any matches, please post them here afterwards.
It is not the goal to conquer all unices, nor to please you or me or any other users. Neither is it a goal to produce comments that can't be misinterpreted out of context either. So what if Theo is an asshoel, so what if he is blunt, uncharismatic, unfriendly or not on your list of likeable persons? He doesn't care for what you like, until you start producing workable code. And neither do I, but I don't run a project like that. He does. And he can say what goes and what doesn't. You (and others) need to figure out really quickly that it's not about you. They don't do all that work for you, it's for _them_.
It may come as a shock for you to realise it, but if you slam the door and never return it wont matter to them. Really. If the (true - as of now) statement offends you so much, by all means go somewhere else. It will not matter. It will not change any facts, and it will not change openbsd, and it will not change the trackrecord of openbsd.
I got the same. A64 on an ASUS mobo. The sata drivers wont work so its time to dig up some shit-old 4G Piomode4-IDE so the most recent version of winxp can "handle" it. 8-(
Try looking for sata drivers, scsidrivers or just any kind of win-drivers made for winxp-amd64. I wont be holding my breath while you google though.
why does it need to rescan all files - even ones that have not changed? Because it takes five minutes to figure out for the virus writer how to trick your scanner that the file ISN'T changed by setting the clock back and touching the file once.
No. The BSD license, or public domain, would allow us to actually USE the code we paid to develop, in the sense of incorporating it into our own works. The MPL precludes that sort of use. That's what makes it a slap in the face of the Linux community, specifically.
Well, you'd be able to use it REALLY REALLY much, if you just license your stuff in an MPL-compatible way, exactly as with any other free/open license. You may use it if your license is compatible, otherwise not. So your bug-up-the-ass is that they chose one that you didn't use yourself. Tough luck.
try this: ----------- int a; a=atoi(getenv("DONT_EXIST")); ----------- to see a short piece which would gain from this. This will only fail when the variable DONT_EXIST doesn't exist, which it obviously will in your own comfy environment, but not in your customers, from where the bomb will be clearly visible. =)
Can you boot off your firewire? Otherwise you still need some cheap drive (that cant be bought in less than 40-50G nowadays!) to boot from, and then let control over to the firewire disk.
Do *NOT* make the same mistake that H323 and SIP has done and make a protocol that can handle NAT. With the shortage of ipv4 addresses (or the silly admins that NAT anyhow) today, you can't use any simple net-audio no more. People seem to be able to do most anything, including GameVoice and stuff, but all the standardised, "serious" software is designed by people on univerisities or other places that never heard of NAT so they constantly design the protocols to send your ip inside the protocol.
Of course, some 2-bit hack kernel module for ip--filtering for linux appears in 6 months, but everyone doesn't want to modify kernels with random modules and unproven code just because netaudio folks seems to think NAT doesn't exist.
I'd love for NAT to go away and die, but unfortunately it wont, so please, if you make an audio app, make it able to survive a simple port forwarding so I can 'call' through my $100 cheap-o-matic SOHO-firewall box.
Example: A hacker sends a packet that exploits a buffer overflow bug to insert some malicious code into memory. The computer won't execute it because it's writeable, and it doesn't execute writeable pages. But that's okay! The worm cleverly inserted the data into a location it knew was writeable, but would eventually become readable. Sure enough, later on another function makes that location executable and then executes it.
The thing is that stuff written to memory by usual apps are written into PROT_WRITE areas. These in turn usually never gets mprotect()ed to another status by the apps. A common exploit would normally send malicious data to the app making the app copy that data into an area that had both PROT_WRITE and PROT_EXEC. Then, it would make the app jump into this area. So, you can always use bugs to have the code jump from one place to another, but if the app doesn't have any mprotect() code (mine never does =) then it would be pretty hard for the exploiter to rewrite the rules of his particurlar page using code that isn't his own at all to make it possible for him to jump into his own code. Until you have found a way to execute your own code, finding a call to mprotect() with *EXACTLY* the correct args to make page 0x056df800 go from PROT_WRITE to PROT_EXEC will be hard++. So you end up with a chicken-egg-problem. The malicious code could of course make its own page PROT_EXEC. if it could execute mprotect(), and since it can't execute anything without PROT_EXEC, it cannot run mprotect() at all.
" Showing my unix age here, why port most of the gnu unix filesystem utilities to SunOS, AIX and Irix?"
Because, for instance, sed on Irix croaks on long strings, ls on Solaris doesn't do colors or such reasons. Sometimes the gnu stuff is better, sometimes prettier and sometimes, you just want to have it behave exactly the same on all platforms. (du, df, bash, make and so on)
As for the other BSD's, having multiple platforms to care for means that you need to make _sure_ that 3.2 will actually make ok code on vax, 88k and other weird uncommon cpu's. The gcc team tests only the "major" setup's and just let the rest tack on and hope they work.
Slashdot Mirror
Because it sucks by having hardware that cant handle memory above 1G, which means either it goes, or your 1+ G machine becomes 1G machine.
(or you start doing the ISA-bus style memory bouncing for all network drivers since any device can DMA to/from the same mbufs that the bce later should handle)
So either a massive rewrite of all other network drivers, OR, kill the driver for the broken hardware that pretends to be useful but isnt.
bah, my neat < > disappeared. After the ::, you get to choose your own number, just like as if you would on a v4 subnet.
Then again, some of us dont use the randomized ipv6 addresses but rather get to choose the numbers ourselves (especially for servers which you may need to enter ips for), and in those cases, you can get away with having to remember five "octets" instead of four, like 2001:abc:def:123:: which means it will be possible to learn for you to use when the DNS is unusable.
Then again, the bug came up while failing to compile xulrunner, so it wasnt hunting for stupid 30+ years old code noone uses, but running a compile of something from this side of the millenium that in the end pointed to this bug.
And if you follow the replies on that link you get to see why server admins don't like clients that grab more resources than necessary.
It works as long as you are the only one doing it, but when everyone starts using segmented downloads, everyone loses. And you not only
go back to as it was before, you also manage to waste more than the same number of poeple would have before, if they would stick to using
one connection per download.
There has been discussions on the openoffice distribution lists about this too. Not everyone is convinced that having each client opens
loads and loads of connections per download is the desired solution in the end.
The windows drivers I've seen on laptops ask their users to enter what country they are in,
meaning it is extremly simple to choose a "better" country for you broadcasting rules if the
current one doesn't allow what you like. How come the FCC dont raid those manufactorers?
I think you're mixing stuff up.
The "blob" part is like the Nvidia binary drivers for X11.
What Theo is asking for is to be allowed to re-distribute the firmwares
for the chips, so that you can use the network card for installs, for instance.
If you are required to go through a webpage and click Yes before you can use
your network card, then it's pretty much useless for installs unless you already
had another network card in there already.
Then, on top of this, he seems to want the specs for the API used to talk to
this firmware-driven hardware, so that they can write a driver of their own.
Big difference there.
* Firmware - please allow us to redistribute verbatim copies of it.
* API - docs in order to write free drivers.
These are two things needed in order to get those intel cards going.
Since the firmware in one way or another already is available on the
net or on the CD in windows-format, there really shouldn't have to be
such a problem to allow redistribution of it. For the API's, everyones
guess as to why you'd need to keep them secret is as good as theirs.
As he states somewhere, not getting these two parts makes the card
unusable anyhow, so there's nothing to lose really.
like why glibc wont have strl*()-functions which may improve security:0 309.html
http://lists.debian.org/debian-devel/2002/03/msg0
It's not like the whole linux world would fall apart if there was some more
string functions which would not go ape on weird inputs.
I know strl*() isn't a magic bullet to prevent all kinds of badness, but they
really can't be worse than the same functions without bounds checking.
Still, better to bash some BSD...
Why aren't someone already doing a SSH of their own then?
Apart from the proof-of-concept-type ssh clients out there (good or bad)
there is *nothing* to stop anyone from taking the same ssh1-code and
reimplementing all the goodies OpenBSD got in there.
Or write a GPL'ed own ssh for the linux crowds. The specs are there,
the protocol isn't secret.
It's not like it isn't possible, its just that building up that kind
of trust seems harder than you'd first imagine. These guys have made
it, others may not.
I've heard Win64 has 32bit longs but 64bits pointers.
One of the reasons for threading an app even on single-cpu systems would be that you dont have to do async IO for one. You can have the emailthread talk net all the "same" as the browser tries to save that 100M pr0n archive you just downloaded. So while the main thread waits for something, the others can run, but usually (when the mozilla developers test it? =) two things never happen exactly at the same time, but on those darned smp machines, it sometimes does.
Then weird stuff breaks and I get another adressbook. (on next start it always says: "Hey, can't read it, I called the old one abook-24234234.bak-something and invented a new one")
Buy an SMP machine and just surf and/or read mail a lot. Works every time for me.
http://people.su.se/~jj/FreeSBIE-1.0-i386.iso.torr ent
There is a difference between:
"He should do X" and
"I think he shoudl do X to achieve Y".
Especially when Y isn't on the goals.html page.
Yes, more users would seem logical, but it's not one
of the goals. Reread it and you'll see.
The response from TdR shouldn't be
Ok, tell me *WHY* it should be any different. And
when you have figured out one or more reasons why it
should be anything different, match those reason to
the list here:
http://www.openbsd.org/goals.html
If you get any matches, please post them here afterwards.
It is not the goal to conquer all unices, nor to
please you or me or any other users. Neither is it
a goal to produce comments that can't be misinterpreted
out of context either. So what if Theo is an asshoel,
so what if he is blunt, uncharismatic, unfriendly
or not on your list of likeable persons? He doesn't
care for what you like, until you start producing
workable code. And neither do I, but I don't run a
project like that. He does. And he can say what goes
and what doesn't. You (and others) need to figure
out really quickly that it's not about you. They
don't do all that work for you, it's for _them_.
It may come as a shock for you to realise it, but
if you slam the door and never return it wont matter
to them. Really. If the (true - as of now) statement
offends you so much, by all means go somewhere else.
It will not matter. It will not change any facts,
and it will not change openbsd, and it will not change
the trackrecord of openbsd.
I got the same. A64 on an ASUS mobo. The sata drivers
wont work so its time to dig up some shit-old 4G Piomode4-IDE
so the most recent version of winxp can "handle" it.
8-(
Try looking for sata drivers, scsidrivers or just any
kind of win-drivers made for winxp-amd64. I wont be
holding my breath while you google though.
why does it need to rescan all files - even ones that have not changed?
Because it takes five minutes to figure out for the
virus writer how to trick your scanner that the
file ISN'T changed by setting the clock back and
touching the file once.
No. The BSD license, or public domain, would allow us to actually USE the code we paid to develop, in the sense of incorporating it into our own works. The MPL precludes that sort of use. That's what makes it a slap in the face of the Linux community, specifically.
Well, you'd be able to use it REALLY REALLY much,
if you just license your stuff in an MPL-compatible
way, exactly as with any other free/open license.
You may use it if your license is compatible, otherwise
not. So your bug-up-the-ass is that they chose one
that you didn't use yourself. Tough luck.
try this:o see a short piece
-----------
int a;
a=atoi(getenv("DONT_EXIST"));
-----------
t
which would gain from this.
This will only fail when the variable DONT_EXIST
doesn't exist, which it obviously will in your
own comfy environment, but not in your customers,
from where the bomb will be clearly visible. =)
Can you boot off your firewire? Otherwise you still
need some cheap drive (that cant be bought in less
than 40-50G nowadays!) to boot from, and then let
control over to the firewire disk.
Do *NOT* make the same mistake that H323 and SIP has
done and make a protocol that can handle NAT.
With the shortage of ipv4 addresses (or the silly
admins that NAT anyhow) today, you can't use any simple
net-audio no more. People seem to be able to do
most anything, including GameVoice and stuff, but
all the standardised, "serious" software is designed
by people on univerisities or other places that never
heard of NAT so they constantly design the protocols
to send your ip inside the protocol.
Of course, some 2-bit hack kernel module for
ip--filtering for linux appears
in 6 months, but everyone doesn't want to modify
kernels with random modules and unproven code just
because netaudio folks seems to think NAT doesn't
exist.
I'd love for NAT to go away and die, but unfortunately
it wont, so please, if you make an audio app, make
it able to survive a simple port forwarding so I
can 'call' through my $100 cheap-o-matic SOHO-firewall
box.
Example: A hacker sends a packet that exploits a buffer overflow bug to insert some malicious code into memory. The computer won't execute it because it's writeable, and it doesn't execute writeable pages. But that's okay! The worm cleverly inserted the data into a location it knew was writeable, but would eventually become readable. Sure enough, later on another function makes that location executable and then executes it.
The thing is that stuff written to memory by usual
apps are written into PROT_WRITE areas. These in
turn usually never gets mprotect()ed to another
status by the apps. A common exploit would normally
send malicious data to the app making the app copy
that data into an area that had both PROT_WRITE
and PROT_EXEC. Then, it would make the app jump into
this area.
So, you can always use bugs to have the code jump
from one place to another, but if the app doesn't
have any mprotect() code (mine never does =) then
it would be pretty hard for the exploiter to rewrite
the rules of his particurlar page using code that isn't
his own at all to make it possible for him to jump
into his own code.
Until you have found a way to execute your own code,
finding a call to mprotect() with *EXACTLY* the correct
args to make page 0x056df800 go from PROT_WRITE to
PROT_EXEC will be hard++.
So you end up with a chicken-egg-problem. The
malicious code could of course make its own page
PROT_EXEC. if it could execute mprotect(), and since it can't
execute anything without PROT_EXEC, it cannot run mprotect() at all.
" Showing my unix age here, why port most of the gnu unix filesystem utilities to SunOS, AIX and Irix?"
Because, for instance, sed on Irix croaks on long
strings, ls on Solaris doesn't do colors or such reasons.
Sometimes the gnu stuff is better, sometimes prettier
and sometimes, you just want to have it behave
exactly the same on all platforms. (du, df, bash,
make and so on)
Next you're gonna tell me that cats and dogs have merged.
At least they rain together.
As for the other BSD's, having multiple platforms
to care for means that you need to make _sure_
that 3.2 will actually make ok code on vax, 88k
and other weird uncommon cpu's. The gcc team
tests only the "major" setup's and just let the
rest tack on and hope they work.