For those who have missed it, point your browser here: /macos-x-beta-1.html> (After having removed the space added after 'macosx-pb1' by slashdot)
Unfortunately, the article is a nice piece of shit (wait a bit before moderating down, please. and read the article. it may also help if you use OS X on a daily basis).
The guy use very technical words to tell the world that what is miss is, mainly, an apple menu. He seems to have trouble keeping itself calm in the last couple of pages. He want is apple menu back. We'll he even reboot in real Mac OS 9, so he can have its apple menu. His OS 9 crashes two times, but, what the hell, he prefers crashing than lacking its fucking apple menu.
If he wants, he can go on www.Stepwise.com (on softrack), where he'll find free replacements for it, but no, no, no. He wants it in _standard_. He wants apple to push its apple menu to every mom and dad of the world.
Apple deserves him the holy apple menu.
There is a rant about the '5 seconds faster to boot that saves 50 lifes', which get in connection with its apple menu at the end. He probably beleives that the apple menu, beeing a so superior design, is probably worth 500 lifes. (Btw, give the time an OS 9 takes to boot and the incessant crashing it have, forcing the switch to OS X on every mac user would probably save the population of a medium city)
But the reality he refuses to face is that the apple menu plain sucks (cluttered. hard to read [icons are smaller than what is generally used for an app]. difficult to use with the nested hierarchies. used as a 'kitchen sink' for every crap in the computer, easy to laucnh the wrong app, impossible to launch several item at once, impossible to drag a document on a menu entry to do 'open with', etc, etc). He is used to it, and I can understand that, but it sucks as much as the windows start menu, or the gnome one. (Worse is better, bad ideas get copied). AND IF HE WANTS ONE, WHY CAN'T HE DOWNLOADS ONE ? By the time it took him to rant about it, I would have WRITTEN one.
There is a pathetic rant about the:
> lack of a universally accessible, user-configurable, hierarchical quick-access > mechanism. [it] is necessary if advanced users are ever to be as efficient in > OS X as they are in classic Mac OS.
Boys, I love the precision of the description.
* universally accessible
--> I want it on the menu bar, at a fixed place (ie: on the top left or top right). In one word, I want a menu
* user-configurable
--> I don't want it do be tied to the filesystem, or filled magically. I want to fill it myself, like the good old apple menu [note: this looks like a advanced feature for Mac OS X. My dad will never find how to fill an apple menu. He dosn't even _exctly_ know the difference between a macintosh and windows (sic)]
* hierarchical quick-access mechanism
--> I want it to be a hierarchical menu
This looks like jobs descriptions used when the guy is already choosed. Maybe he could have added:
* colorfull
--> As it is easier to spot. Maybe it could have rainbows color, so I could use it to check if I am not on a monochrome monitor. I would recommend the representation of a fruit, but a company logo could do well too
I also love the various attempt at 'the apple logo in the middle of the screen have no use', remove it, or (better) find a use for it (hint, hint)
Mac looser at its best.
Why don't he says what his trouble really is ?
Finding and launching applications and documents is painfull. There are other means to solve that than the apple menu. (For instance: search for NeXTstep 4.0 alpha screenshot on the web. There was a fantastic shelf in this version that never made it into 4.0. Pity).
This is something that apple can understand and take into account. Pushing an crappy concept in the new os is just plain stupid. And there is a lot more missing in OS X than the apple menu.
I bet apple have already the apple menu somewhere, but want to wait for 1.0 so jobs can make the holy demo: clicking on the apple, and having the menu down.
I already see al the suckers applauding.
Okay, now you can moderate down to (-1) flamebait.
> You are just responding to a troll which posted the same exact message last time HURD came up.
I suspected it. But I like trolls. I don't want them to die starved, so I have to feed them...:-)
More seriously, there are many non-developers there that may not understand the value of a non-monolothic system. Thes CDRW story really pissed me off. What good having the system sources is if I can't successfully hack them ?
> The problem with the HURD is that it is still obsessed with the microkernel architecture
It is the only advantage of the HURD versus linux. We already have plenty of monolitic kernel to choose from.
> This may have seemed like a good bet ten years ago, but as Linux has shown, Microkernels are no big deal
This is plain wrong. There are many microkernels out there. They offer no specific advantage to monolithic kernels, but the HURD is a very different beast: A multi-server micro-kernel.
> They are inefficient
Bullshit. You are comparing highly tuned monolithic kernels to development micro kernels. This is apple and oranges, or mindcraft-like attitude.
Sure, micro-kernels are inefficient to perform the tasks that monolithic kernels have been designed to perform. Big deal. But there are tasks that are impossible to perform with a monolithic kernel. When you'll base you benchmark on them, you'll say that monolitic kernels are inefficient.
A couple of examples:
Two years ago I had my first CD-RW. Someone showed me Direct-CD under windows, and I said: "Woov. Cool. How does it works. Can I do that under linux".
Digged around. Found the UDF filesystem project and specs. Found the packet writing specs. Found that there were no packet-writing UDF driver under linux. Found the reason. "Currently you'll only be able to read CDR/CDRWs due to a kernel limitation". So what ? Well, I tried to find what the limitation is, to find if it was possible to work around, and do a packet-writed file system. Unfortunately, due to optimisation in the linux kernel it is not possible. But it may be possible later. Just wait. As you may know if you follow the linux kernel traffics, Linus specifically make it hard to become a kernel hacker, so the ones that hack the kernel are only the most motivated ones. Conclusion: No way to mount and modify a UDF packet-written filesystem. Period. The complexity of the kernel architecture and source rendered linux as closed as a proprietary kernel.
A UDF driver would be possinle under the HURD without having to touch more things than neccessary (It would be called a translator. This is like a user-space file system). It will be less efficient sure. But noone gives a fuck to high efficiency when writing to such a slooow device.
Example 2: Having drivers as server outside the kernel in a network transparent architecture (like mach is), should give you ideas of what will be possible. (Remote physical devices. Who mind a little efficiency loss when you access an USB bus from a different network point)
> and the chances of a code fork with Hurd are even greater than for Linux, due to the easier understandibility of the source code.
> > (I should note that the change could have been done silently, so that you wouldn't have known who changed the password on your account.)
>
> I've never thought much of you, michael, but you've far exceeded my expectations here. You positively drip with hypocrisy.
He just fucked up by not remembering that an email would be sent. Hypocrit _and_ stupid. Lol.
> Uhm, the code you posted looks just like what I posted
Yes. I asked if it was really what you meant.:-)
I *though* I understood what you wanted to say (each step of the computation are done in parallel, so 'b' value used in the last step must be 4 generation old, but didn't see why the way you wrote it was an improvment...
I get it now. The logic behind the execution is, from the point of view of the processor:
First I do:
b= a[i] (Can't do anything else)
Now I have b, so I can do
c = b + t || b1 = b
As I don't need b anymore, I can fetch the next one now, so the second cycle looks like:
c = b + t || b1 = b || b = a[i+1]
Etc, etc. The b3,b2,b1,b is the pipleline for b values. At the end, we have one new g[i] value at each cycle. Neat.
Thanks a lot, I never realised that adding instruction between stalled cycles could sped up the process (I always thought that there were slots 'for free', but not that it could accelerate the result). Make sense in reality, because by using the b1/b2/b3 we are giving more temporary memory for the execution...
for (i = 0; i < N; i++)
{ b = a[i];
b1 = b;
b2 = b1;
b3 = b2;
c = b + t;
d = c + u;
e = d + v;
g[i] = e + b3;
}
IU fail to see why this is an improvment on the original code. And the additions are still dependant on each other and can't be executed at the same step. Or I misunderstood everything...
> FreeBSD documents *everything* - commands, file formats, even man style which documents the bsd style for formatting c code. You also have info pages as well as original papers on ipc, sendmail, etc, etc
And on drivers.
Installed a debian yesterday. Wanted to use generic scsi. Looked for/dev/sg*. Nothing man sg. Nothing. man scsi. Nothing. vi/dev/MAKEDEV. Oh, great, let's try./MAKEDEV sg. Then randomly use/dev/sg0,/dev/sg1, etc (because the doc I had said that sg devices were numbered from sg[a-z]. Something may have changed somewhere. Who knows ?)
Bzzzt. EOF is not present in Mac OS X. (Yes, they fucked that too)
Apple just promised to release a ObjC EOF for Mac OS X after consumer releases (Which don't means anything, as apple promises have about no incidence on reality)
But, in the big picture, yes, Mac OS X == NeXTstep 6 (which much more bugs...)
> However, having it all in one tree still seems to make some sense: It will all be the same kernel, but if I compile for my pentium I won't have to include stuff for alphas, handhelds, or supercomputers
Sure, but it'll be a huge tarball (which is not a big deal). What is worse is that it will _always_ be broken.
Let's see the different level of modificaitons possible:
1/ A change that is good for everyone. No problem, it goes into the mainstream kernel.
This is what your original post was about
2/ A addition ("include stuff") that is good for some people, but useless for other people. No problem, you wrap it into a CONFIG option.
This is what you are talking about now.
3/ A change that is good for people but that would harm others (even if not enabled. It would populate the kernel with hundreds of #ifdef). Here, I am talking about big changes, like real time. Those are maintained off-line, in patches.
But, such changes are harder and harder to maintain. At one point, it will be more work to tweak the code so the patch still work, than it would be to re-implement (cut'n'paste) the kernel new features. And the patches would be in so many parts of the kernel that they would confict with other patches out there (ie: if, when you apply the handhelds patch, you can't apply most of the other patches out there, it means that the result is hardly linux)
This would be the the 4th kind of kernel modifications:
4/ Modifications that are so invasive that the result cannot be called linux anymore. Those deserve forks. And in that case it would be a good thing (note that you can bet that the fork would stay compatible with the model used for drivers, filesystem, and won't be a total alien)
(And there is always the classical ego-fork. Linux is probably safe from this because Linus is incontested. But, if he was hit by a bus...)
Cheers,
--fred
Re:But it won't happen and it doesn't matter
on
Linux to Fragment?
·
· Score: 2
> Someone adds something worthwhile to linux - the other distributions will simply incorporate it as allowed by the GPL.
For the kernel yes. But not for userland.
If a vendor make a linux distribution with a proprietary thing on it (say a critical user-space library), he doesn't have to make it GPL. Or a vital application (say a VMWare distribution with a bundle VMWare).
What keep linux together is that the GPL prevent linking with a proprietary component, so any proprietary add-on must be self-contained.
But, I repeat myself, IBM could do a BlueLinux distribution, with a libibm (containing interfaces to the transaction manager, MQ-series, anythiung you want), and getting application suppliers (or their own db2) to link and use those libraries. Another case would be a very hypothetical AppleLinux with Quartz. Could be free-as-beer, but if you buy an AppleLinux application, it is only going to work with AppleLinux.
This is a threat when big names will produce their own tweaked linux. Don't think it will be all-GPLed.
>...that most people would be smart enough not to fork the kernel. Even if they did, they would have to release the code and anything good would eventually make it back into the main tree anyway,
I hope not. You can't reasonably expect _everything_ be right for both embeddeed markets and 32 processors. Or the latency/bandwidth trade off are definitely not the same in normal and real-time environment.
So basically, kernel forks won't be that bad.
Much more painfull would be vendor forks (ie: where there is no technical reason for the forks), that would deliberately make incompatible versions to lock users in their marketshare. Nothing that can't be hacked around, but it would be painfull to have to use specific distributions for specific applications. You'll end up emulating 'flavors' of each distro on each other, and well, it would sucks.
You will probably not beleive me, but I never heard of 'Sneakers' before. Went to imdb, looks like the movie is exactly about this. Mmm. French name 'Les Experts'. I'll try to find it.
> They may already have a O(lg n) or O(n) factoring algorithm, where n is (respectively) the number or the number of digits in the number.
> They may already have broken discrete log.
I often think about this. I wonder what they would do in such a case. Shoting the guy that invented the factorisation stuff would be an obvious start, then hiring everyone on a path to the solution and making them work in such a way that they never find it. And probably killing the coders that implemented the cracking algorithms.
I mean, this would be the one of the most protected secret ever. I can't even imagine what security level would be needed for this one...
> I mean the whole idea re fqdn is for us humans to not have to deal w/ numbers, yes?
Not really. Thd DNS system have been badly abused by the Internet rush. Those names were not supposed to be seen by humans, but were handles to specific resources. The real DNS was supposed to be something like Google, or Real Names.
Their idea is not as dumb as I originally thought. Phone numbers are already a way to uniquely indentify a service. Those numbers are ubiquitous. With more and more cell phones getting internet access, the thing may make a bit of sense. You try to reach your friend, but don't find him. You can directly go to its website, or whatever. Or someone calls you. With caller-id, you can have more informations. Or you want to a professional. You get its number from a phonebook, and you can get to its web-site to check its hourly rates, or whatever. Sure, it is dumb because if you were on a computer, you have probably got its number via the web, and if he had a webpage, it would probably been indicated next to the number.
The problem of Adobe with a Mac OS X version would not be about the unix flavor but about the GUI. What to use ? Cocoa ? Carbon ? Don't think that a X11 version on Mac OS X would be viable.
Note that there was a NeXTstep version of Framemaker. Mmmm. Maybe they still have the technical expertise in house for ObjC/AppKit... A Cocoa version of framemaker would just rocks.
> CPU clock rates have experienced an exponential growth, leaving the rest of the PC components behind
I tend to disagree. Hard drive capacity had an exponential growth too. And hard drive bandwith too. And memory size. 1 had 4Mh computers with 64Kb of RAM. Now I have a 800Mhz (x200) with 512 Mb of RAM (x8192)
My hard drives went from 20Mb on a 25 Mhz machine, and now it is 40Gb (x2000) on a 800Mhz (x32). And disk bandwidth went from 500K/s in 1991 (with good expensive SCSI hardware) to about 20Mb/s on ATAPI disk.
Most component of a PC had an exponential growth. But agreed, there is a problem with memory latency. And display quality. And CPU count. And noise. And size. And heat (well, one could argue that heat had an exponential growth too:-) )
Question :
"If there's another OS came out that was a Free OS and started doing well then
will we see something like Red Hat BSD or something?"
Answer:
I think comes back to the critical mass question. I think that for Red Hat,
it's better to enhance our technical solutions to meet customer requirements
than it is to dilute our brand with other operating systems that don't have
the critical mass of Red Hat Linux or eCos.
Huh ? The critical mass of 'eCos' vs 'BSD's ? Unfortunately, this stupidity is at the end. If it have been at the top, I woundn't bothered reading all this poor inteview.
> Since you're the copyright owner of the document, unless you're totally wigged out on cough syrup, I can't imagine you not giving yourself permission.
So it will be legal to crack you own documents. Great. But as the software needed to crack will be illegal, it will be impossible.
I have a lot of slides. In the future, digital camera may take picture in proprietary encrypted formats. Those could be viewed only on specific devices (and be lost the day where the maker of the device goes out of business)
Note that digital information is often harder to preserve than non-digital information (ie: anyone getting its hands on a few millions of Word documents in one hundred years will be in deep troubles).
Slashdot Mirror
First the
"HURD is still coming" and now, "the young are increasingly coming".
I somewhat understand the "moral panic" out there...
Cheers,
--fred
For those who have missed it, point your browser here:/macos-x-beta-1.html> (After having removed the space added after 'macosx-pb1' by slashdot)
Unfortunately, the article is a nice piece of shit (wait a bit before moderating down, please. and read the article. it may also help if you use OS X on a daily basis).
The guy use very technical words to tell the world that what is miss is, mainly, an apple menu. He seems to have trouble keeping itself calm in the last couple of pages. He want is apple menu back. We'll he even reboot in real Mac OS 9, so he can have its apple menu. His OS 9 crashes two times, but, what the hell, he prefers crashing than lacking its fucking apple menu.
If he wants, he can go on www.Stepwise.com (on softrack), where he'll find free replacements for it, but no, no, no. He wants it in _standard_. He wants apple to push its apple menu to every mom and dad of the world.
Apple deserves him the holy apple menu.
There is a rant about the '5 seconds faster to boot that saves 50 lifes', which get in connection with its apple menu at the end. He probably beleives that the apple menu, beeing a so superior design, is probably worth 500 lifes. (Btw, give the time an OS 9 takes to boot and the incessant crashing it have, forcing the switch to OS X on every mac user would probably save the population of a medium city)
But the reality he refuses to face is that the apple menu plain sucks (cluttered. hard to read [icons are smaller than what is generally used for an app]. difficult to use with the nested hierarchies. used as a 'kitchen sink' for every crap in the computer, easy to laucnh the wrong app, impossible to launch several item at once, impossible to drag a document on a menu entry to do 'open with', etc, etc). He is used to it, and I can understand that, but it sucks as much as the windows start menu, or the gnome one. (Worse is better, bad ideas get copied). AND IF HE WANTS ONE, WHY CAN'T HE DOWNLOADS ONE ? By the time it took him to rant about it, I would have WRITTEN one.
There is a pathetic rant about the:
> lack of a universally accessible, user-configurable, hierarchical quick-access > mechanism. [it] is necessary if advanced users are ever to be as efficient in > OS X as they are in classic Mac OS.
Boys, I love the precision of the description.
* universally accessible
--> I want it on the menu bar, at a fixed place (ie: on the top left or top right). In one word, I want a menu
* user-configurable
--> I don't want it do be tied to the filesystem, or filled magically. I want to fill it myself, like the good old apple menu [note: this looks like a advanced feature for Mac OS X. My dad will never find how to fill an apple menu. He dosn't even _exctly_ know the difference between a macintosh and windows (sic)]
* hierarchical quick-access mechanism
--> I want it to be a hierarchical menu
This looks like jobs descriptions used when the guy is already choosed. Maybe he could have added:
* colorfull
--> As it is easier to spot. Maybe it could have rainbows color, so I could use it to check if I am not on a monochrome monitor. I would recommend the representation of a fruit, but a company logo could do well too
I also love the various attempt at 'the apple logo in the middle of the screen have no use', remove it, or (better) find a use for it (hint, hint)
Mac looser at its best.
Why don't he says what his trouble really is ?
Finding and launching applications and documents is painfull. There are other means to solve that than the apple menu. (For instance: search for NeXTstep 4.0 alpha screenshot on the web. There was a fantastic shelf in this version that never made it into 4.0. Pity).
This is something that apple can understand and take into account. Pushing an crappy concept in the new os is just plain stupid. And there is a lot more missing in OS X than the apple menu.
I bet apple have already the apple menu somewhere, but want to wait for 1.0 so jobs can make the holy demo: clicking on the apple, and having the menu down.
I already see al the suckers applauding.
Okay, now you can moderate down to (-1) flamebait.
Cheers,
--fred
> You are just responding to a troll which posted the same exact message last time HURD came up.
:-)
I suspected it. But I like trolls. I don't want them to die starved, so I have to feed them...
More seriously, there are many non-developers there that may not understand the value of a non-monolothic system. Thes CDRW story really pissed me off. What good having the system sources is if I can't successfully hack them ?
And well, maybe I was karma whoring a bit...
Cheers,
--fred
> The biggest myth is the one put out by you microkernel freaks is that the linux kernel is a monolithic kernel. It's not. It's a hybrid.
Could you back up this assertion, please ?
Cheers,
--fred
> The problem with the HURD is that it is still obsessed with the microkernel architecture
It is the only advantage of the HURD versus linux. We already have plenty of monolitic kernel to choose from.
> This may have seemed like a good bet ten years ago, but as Linux has shown, Microkernels are no big deal
This is plain wrong. There are many microkernels out there. They offer no specific advantage to monolithic kernels, but the HURD is a very different beast: A multi-server micro-kernel.
> They are inefficient
Bullshit. You are comparing highly tuned monolithic kernels to development micro kernels. This is apple and oranges, or mindcraft-like attitude.
Sure, micro-kernels are inefficient to perform the tasks that monolithic kernels have been designed to perform. Big deal. But there are tasks that are impossible to perform with a monolithic kernel. When you'll base you benchmark on them, you'll say that monolitic kernels are inefficient.
A couple of examples:
Two years ago I had my first CD-RW. Someone showed me Direct-CD under windows, and I said: "Woov. Cool. How does it works. Can I do that under linux".
Digged around. Found the UDF filesystem project and specs. Found the packet writing specs. Found that there were no packet-writing UDF driver under linux. Found the reason. "Currently you'll only be able to read CDR/CDRWs due to a kernel limitation". So what ? Well, I tried to find what the limitation is, to find if it was possible to work around, and do a packet-writed file system. Unfortunately, due to optimisation in the linux kernel it is not possible. But it may be possible later. Just wait. As you may know if you follow the linux kernel traffics, Linus specifically make it hard to become a kernel hacker, so the ones that hack the kernel are only the most motivated ones. Conclusion: No way to mount and modify a UDF packet-written filesystem. Period. The complexity of the kernel architecture and source rendered linux as closed as a proprietary kernel.
A UDF driver would be possinle under the HURD without having to touch more things than neccessary (It would be called a translator. This is like a user-space file system). It will be less efficient sure. But noone gives a fuck to high efficiency when writing to such a slooow device.
Example 2: Having drivers as server outside the kernel in a network transparent architecture (like mach is), should give you ideas of what will be possible. (Remote physical devices. Who mind a little efficiency loss when you access an USB bus from a different network point)
> and the chances of a code fork with Hurd are even greater than for Linux, due to the easier understandibility of the source code.
Oh, you were trolling. Guess what, I felt for it.
Cheers,
--fred
> what are all those 'Unable to connect to ad server' messages sprinkled around the text
Have the same without junkbuster. I think they fucked something at Dr Daube.
Cheers,
--fred
Bababooey to you. "what Win3.11 would have looked like had the Germans designed it". lol.
You made my day. Thx.
Cheers,
--fred
> > (I should note that the change could have been done silently, so that you wouldn't have known who changed the password on your account.)
>
> I've never thought much of you, michael, but you've far exceeded my expectations here. You positively drip with hypocrisy.
He just fucked up by not remembering that an email would be sent. Hypocrit _and_ stupid. Lol.
Cheers,
--fred
> Uhm, the code you posted looks just like what I posted
:-)
Yes. I asked if it was really what you meant.
I *though* I understood what you wanted to say (each step of the computation are done in parallel, so 'b' value used in the last step must be 4 generation old, but didn't see why the way you wrote it was an improvment...
I get it now. The logic behind the execution is, from the point of view of the processor:
First I do:
b= a[i] (Can't do anything else)
Now I have b, so I can do
c = b + t || b1 = b
As I don't need b anymore, I can fetch the next one now, so the second cycle looks like:
c = b + t || b1 = b || b = a[i+1]
Etc, etc. The b3,b2,b1,b is the pipleline for b values. At the end, we have one new g[i] value at each cycle. Neat.
Thanks a lot, I never realised that adding instruction between stalled cycles could sped up the process (I always thought that there were slots 'for free', but not that it could accelerate the result). Make sense in reality, because by using the b1/b2/b3 we are giving more temporary memory for the execution...
Cheers,
--fred
I am lost here.
Did you really mean:
for (i = 0; i < N; i++)
{ b = a[i];
b1 = b;
b2 = b1;
b3 = b2;
c = b + t;
d = c + u;
e = d + v;
g[i] = e + b3;
}
IU fail to see why this is an improvment on the original code. And the additions are still dependant on each other and can't be executed at the same step. Or I misunderstood everything...
Cheers,
--fred
> FreeBSD documents *everything* - commands, file formats, even man style which documents the bsd style for formatting c code. You also have info pages as well as original papers on ipc, sendmail, etc, etc
/dev/sg*. Nothing man sg. Nothing. man scsi. Nothing. vi /dev/MAKEDEV. Oh, great, let's try ./MAKEDEV sg. Then randomly use /dev/sg0, /dev/sg1, etc (because the doc I had said that sg devices were numbered from sg[a-z]. Something may have changed somewhere. Who knows ?)
And on drivers.
Installed a debian yesterday. Wanted to use generic scsi. Looked for
Cheers,
--fred
Congrats Bob.
The 'stack frame buffer' idea is just neat. Too bad there as soo much humorless moderators out there...
Cheers,
--fred
Bzzzt. EOF is not present in Mac OS X. (Yes, they fucked that too)
Apple just promised to release a ObjC EOF for Mac OS X after consumer releases (Which don't means anything, as apple promises have about no incidence on reality)
But, in the big picture, yes, Mac OS X == NeXTstep 6 (which much more bugs...)
Cheers,
--fred
> However, having it all in one tree still seems to make some sense: It will all be the same kernel, but if I compile for my pentium I won't have to include stuff for alphas, handhelds, or supercomputers
Sure, but it'll be a huge tarball (which is not a big deal). What is worse is that it will _always_ be broken.
Let's see the different level of modificaitons possible:
1/ A change that is good for everyone. No problem, it goes into the mainstream kernel.
This is what your original post was about
2/ A addition ("include stuff") that is good for some people, but useless for other people. No problem, you wrap it into a CONFIG option.
This is what you are talking about now.
3/ A change that is good for people but that would harm others (even if not enabled. It would populate the kernel with hundreds of #ifdef). Here, I am talking about big changes, like real time. Those are maintained off-line, in patches.
But, such changes are harder and harder to maintain. At one point, it will be more work to tweak the code so the patch still work, than it would be to re-implement (cut'n'paste) the kernel new features. And the patches would be in so many parts of the kernel that they would confict with other patches out there (ie: if, when you apply the handhelds patch, you can't apply most of the other patches out there, it means that the result is hardly linux)
This would be the the 4th kind of kernel modifications:
4/ Modifications that are so invasive that the result cannot be called linux anymore. Those deserve forks. And in that case it would be a good thing (note that you can bet that the fork would stay compatible with the model used for drivers, filesystem, and won't be a total alien)
(And there is always the classical ego-fork. Linux is probably safe from this because Linus is incontested. But, if he was hit by a bus...)
Cheers,
--fred
> Someone adds something worthwhile to linux - the other distributions will simply incorporate it as allowed by the GPL.
For the kernel yes. But not for userland.
If a vendor make a linux distribution with a proprietary thing on it (say a critical user-space library), he doesn't have to make it GPL. Or a vital application (say a VMWare distribution with a bundle VMWare).
What keep linux together is that the GPL prevent linking with a proprietary component, so any proprietary add-on must be self-contained.
But, I repeat myself, IBM could do a BlueLinux distribution, with a libibm (containing interfaces to the transaction manager, MQ-series, anythiung you want), and getting application suppliers (or their own db2) to link and use those libraries. Another case would be a very hypothetical AppleLinux with Quartz. Could be free-as-beer, but if you buy an AppleLinux application, it is only going to work with AppleLinux.
This is a threat when big names will produce their own tweaked linux. Don't think it will be all-GPLed.
Cheers,
--fred
> ...that most people would be smart enough not to fork the kernel. Even if they did, they would have to release the code and anything good would eventually make it back into the main tree anyway,
I hope not. You can't reasonably expect _everything_ be right for both embeddeed markets and 32 processors. Or the latency/bandwidth trade off are definitely not the same in normal and real-time environment.
So basically, kernel forks won't be that bad.
Much more painfull would be vendor forks (ie: where there is no technical reason for the forks), that would deliberately make incompatible versions to lock users in their marketshare. Nothing that can't be hacked around, but it would be painfull to have to use specific distributions for specific applications. You'll end up emulating 'flavors' of each distro on each other, and well, it would sucks.
Cheers,
--fred
> Yes, I enjoyed the movie "Sneakers" too.
You will probably not beleive me, but I never heard of 'Sneakers' before. Went to imdb, looks like the movie is exactly about this. Mmm. French name 'Les Experts'. I'll try to find it.
Thanks,
--fred
> They may already have a O(lg n) or O(n) factoring algorithm, where n is (respectively) the number or the number of digits in the number.
> They may already have broken discrete log.
I often think about this. I wonder what they would do in such a case. Shoting the guy that invented the factorisation stuff would be an obvious start, then hiring everyone on a path to the solution and making them work in such a way that they never find it. And probably killing the coders that implemented the cracking algorithms.
I mean, this would be the one of the most protected secret ever. I can't even imagine what security level would be needed for this one...
Cheers,
--fred
> I mean the whole idea re fqdn is for us humans to not have to deal w/ numbers, yes?
Not really. Thd DNS system have been badly abused by the Internet rush. Those names were not supposed to be seen by humans, but were handles to specific resources. The real DNS was supposed to be something like Google, or Real Names.
Their idea is not as dumb as I originally thought. Phone numbers are already a way to uniquely indentify a service. Those numbers are ubiquitous. With more and more cell phones getting internet access, the thing may make a bit of sense. You try to reach your friend, but don't find him. You can directly go to its website, or whatever. Or someone calls you. With caller-id, you can have more informations. Or you want to a professional. You get its number from a phonebook, and you can get to its web-site to check its hourly rates, or whatever. Sure, it is dumb because if you were on a computer, you have probably got its number via the web, and if he had a webpage, it would probably been indicated next to the number.
All in all, it is not 100% stupid. Just 90%...
Cheers,
--fred
> They are making a BSD version
The problem of Adobe with a Mac OS X version would not be about the unix flavor but about the GUI. What to use ? Cocoa ? Carbon ? Don't think that a X11 version on Mac OS X would be viable.
Note that there was a NeXTstep version of Framemaker. Mmmm. Maybe they still have the technical expertise in house for ObjC/AppKit... A Cocoa version of framemaker would just rocks.
Cheers,
--fred
> CPU clock rates have experienced an exponential growth, leaving the rest of the PC components behind
:-) )
I tend to disagree. Hard drive capacity had an exponential growth too. And hard drive bandwith too. And memory size. 1 had 4Mh computers with 64Kb of RAM. Now I have a 800Mhz (x200) with 512 Mb of RAM (x8192)
My hard drives went from 20Mb on a 25 Mhz machine, and now it is 40Gb (x2000) on a 800Mhz (x32). And disk bandwidth went from 500K/s in 1991 (with good expensive SCSI hardware) to about 20Mb/s on ATAPI disk.
Most component of a PC had an exponential growth. But agreed, there is a problem with memory latency. And display quality. And CPU count. And noise. And size. And heat (well, one could argue that heat had an exponential growth too
Cheers,
--fred
Question :
"If there's another OS came out that was a Free OS and started doing well then
will we see something like Red Hat BSD or something?"
Answer:
I think comes back to the critical mass question. I think that for Red Hat,
it's better to enhance our technical solutions to meet customer requirements
than it is to dilute our brand with other operating systems that don't have
the critical mass of Red Hat Linux or eCos.
Huh ? The critical mass of 'eCos' vs 'BSD's ? Unfortunately, this stupidity is at the end. If it have been at the top, I woundn't bothered reading all this poor inteview.
Cheers,
--fred
lol. That is exactly my feeling about it.
So it will be legal to crack you own documents. Great. But as the software needed to crack will be illegal, it will be impossible.
Cheers,
--fred
I have a lot of slides. In the future, digital camera may take picture in proprietary encrypted formats. Those could be viewed only on specific devices (and be lost the day where the maker of the device goes out of business)
Note that digital information is often harder to preserve than non-digital information (ie: anyone getting its hands on a few millions of Word documents in one hundred years will be in deep troubles).
Cheers,
--fred