>Why is it doubtful that the kernel comes into play?
Because BeOs proponents usually talked about their GUI subsystem, or the multithreaded design of their apps, not of their kernel, that's why I don't think that the kernel
>- Interactive patches (preempt, ll, et al) I installed the intertactive patches on the 2.4 kernel and I didn't see any difference in the responsiveness of the applications.
>- IP QoS Uh? We're talking about the responsiveness of X locally.. So IP has nothing to do with it.. Beside as we're talking about X, X is not ideal for remote connections, I believe that a higher level protocol with more things done in the server would be more responsive and use less bandwith..
> Alright, people need to listen closely. XFree86 is NOT SLOW, the toolkits you lay on top of it are what bogs it down.
So if you use a ugly looking desktop X is fast, but if you use a modern looking desktop X is slow, both with KDE and Gnome.
There are two possibilities: - either KDE and Gnome are both slow - or X itself is not well adaptated to modern needs, so we could say that X is slow.
BeOS feels much faster than KDE or Gnome, so it *is* possible to have a fast modern looking desktop, either it was because BeOS kernel was fast (doubtfull) or because it had a better GUI subsystem, or maybe because the apps were better designed..
>Because it wasn't in Apple's interests. Mac users are willing to pay Apple prices, so Apple has enormous profit margins.
But low volumes! Low volume imply fewer software written for MacOS, so people won't buy Apple's computer because there are fewer software --> dwindling market share. This is a vicious circle which has caused Apple to catter to niches where it was successfull. But this niche strategy is fragile: it is quite easy to loose a niche (education has been lost), it is very difficult to build a "new niche".
Apple is lucky that Microsoft has ported its Office product otherwise they would be in an even worse situation..
The reasonning is: 1. the repartition of the e/e-bar annihlations follows the mass repartition, not the repartition of the visible matter. 2. they don't know what mechanism of ordinary matter could cause these e/e-bar annihlation, so they associate it with dark matter.
I agree that this second hypothesis seems a bit risky, but it doesn't seems unreasonnable too, so calling it a "miracle step" is a bit too far IMHO: by definitions miracles are unreasonnable:-)
Re:PowerPC Linux users had compiled boot 'scripts'
on
Booting Linux Faster
·
· Score: 1
>*reboot* gentoo in under 30 seconds, INCLUDING X. What else do you want?
Having KDE running on top of X, and being logged on automatically and doing this under 10seconds?
>Our ongoing failure to connect all the dots of the various paradigms could indicate that he[Einstein] was on to something...
I'm afraid not: there is a famous "thought experiment" proposed by Einstein, Podolsky and Rosen which would "proove" that quantum mechanic is incomplete.
Alain Aspect turned this "thought experiment" into reality in the 80's and he found that reality didn't agree with Einstein!
Of course everybody agrees that quantum mechanic is not the full truth, that's why researchers comes with such weird things as string theories, but the thing is: reality don't comply with the way Einstein was thinking about it..
PS: this is not at all a criticism of Einstein, as I think that the EPR paradox is really really interesting, and weird also!
>True, programming errors can lead to crashes and security problems. But at least you can easily fix those.
(sarcasm) Yes, that's why all the apps that we have today are so secure! (/sarcasm) As for the crash, if the crash is easily reproducible, yes it is easy to fix, but how about the misterious, non-reproducible crash, that happens only when the load is high, so only when your client DOESN'T want your app to crash?
It can be very,very hard to correct..
>>Yes, Python is much slower than C, but is-it too slow for the application considered or is-it fast enough? >Who knows? Why take chances?
You'll copy me one thousand times: "premature optimisation is the root of all evil!"
Python or Ruby are easier to use, and faster to program with, if you find a performance problem then coding this part in C is usually not too hard.. Coding everything in C for a high-level app which should be doable in Python,Ruby or Java is premature optimisation..
> I don't want to use a decent editor, I want to use Vi!
Well use vim, then!
>Now that I've managed to piss off as many people as possible, why Python?
For these kind of apps, Python, Ruby or maybe Java would be the "better choice" really. I prefer Ruby but many more people know Python, so IMHO Pyhon would be a logical choice.
>Doing it explicitly reduces the chances of nasty surprises later on [cut]
Well the nasty surprise you're talking about are in a GC environement: too much memory usage, bad performance. When you do it by hand, a bad memory handling will usually cause crashes, security problems,etc.. I prefer the problems associated with the GC, thanks!
>Python is slow compared to C. Yes, Python is much slower than C, but is-it too slow for the application considered or is-it fast enough?
Could you give a reference? Qt/X11 is GPL, if wxWindows over Qt is GPL too then their wouldn't be any problem. I don't think that a wxWindows could be LGPL if it was made above Qt, but I'm not sure..
> Most people that make any significant contributions to their field do so before they're 30. Einstein's most significant contribution: generalised relativity, was made between 1912 and 1915, and he was born on 1879.
Which means when he was between 33 and 36 years old, yes he made other discory before he was 30 year old, but generalised relativity is really his "chef d'oeuvre" IMHO.
I had troubles making my hw works correctly: - my mousewheel had problems! - the sound never worked really correctly with multiple sounds at the same time.. - installing an ADSL USB modem was a pain: I needed to recompile a kernel: with a Celeron 333, it took a whole night! It took me three week-ends to make it work. - the interface felt sluggish and ugly: but I've recently seen a PC with RedHat: the fonts are much better than they used to be.
Maybe all this was Mandrake faults, but all the "small modifications" needed to make Linux work correctly annoyed me and I went back to Windows (XP is stable enough for my need), and I am happily using Mozilla, Ruby, IrfanView (etc..) on it.
Now if I could have an XTerm and the Unix copy/paste style (with the mouse) working on WinXP, it would be wonderfull..
Strange, I could have sworn that Sun wanted to use Java *everywhere*: - in the client:it failed, Swing was (is still?) slowwww, buggy, leaky. Each time I see a Java app, I can recognise it: it's slow and it looks awfull.. - in embedded stuff : the jury is still out here. - in the web browser: it mostly failed, applets are rare.
So the enterprise app server is not THE focus of Java, it is just one of the domain where Java have not failed..
I'm not sure if you're agreeing or desagreeing with me.
Yes to create a new object you use !! in Eiffel, it could be better true but still its syntax is far more elegant than C++, no?
I think that the best syntax to create an object is in Limbo (a script language in Plan9), you can say: var_name: type_name; as in Pascal but you can also say other_var:= var_name; which is equivalent to say other_var: type_name; other_var = var_name;
Nice, no? This way when you change the type of var_name, you change also the type of other_var..
Eiffel has all these feature with a nice syntax. Eiffle do not have interface, but I don't see the difference between interfaces and abstract virtual base classes, when you have multiple inheritence.
Apparently, it is quite possible to have both GC and manual memory management: C# have it.. I like the idea of having GC by default (secure and easy to use) and still being able to manage memory "by hand" if there is a need.
Oh and I disagree that C++ *has* to be that complex: Eiffel has multiple-inheritence, templates,etc.. and its syntax is very nice..
>Speak for yourself, man -- my role model is Willow Rosenberg. Given that she is a fictional Jewish lesbian witch who almost ended the world, which >doesn't really describe anything about me, that might be strange, but then again, she certainly ain't "stupid".
Yes, but Willow isn't the principal hero of the show: Buffy is! And at first, Buffy wasn't very different of the "stupid blond" role model!
>Lightwave has a pipeline that's like 390 bits wide
According to their website, their full precision renderer use 128bits: 32 bits for each component (RGBA). I doubt that the integer register are used that much for processing the pixels, so for processing reason the 64-bitness is not so much important.
On the other hand, for memory adressing the 64-bitness matter: I wouldn't be surprised that a process could use more that 4 GB to do the rendering..
I'm not sure if you disagree with me: what I said is that I am AGAINST having a type attribute inside a file.
Otherwise what prevents someone creating a file named foo.ogg with an attribute 'type=exe' inside?
Keeping the type in the filename is not a perfect defense of course, but the 'type within attribute' setup do not protect the user, it only makes the problem worse!
While I agree that using a uniform metadata system and a Plan9-like OS could be very insteresting, I think that the type should be kept within the filename (foo.ogg) instead of having a file foo with an attribute type=ogg inside.
Why? For the same reason, that we use name for files instead of numbers: it's easier for the users. If you embed the type inside an attribute, what happen if you have a file foo.ogg with an attribute type=exec ? Lots of problems for the users!
The type attribute is special IMHO: it tells the users what this file will be used for.
If I download a file foo.ogg, I'm not especially carefull before activating it in my browser (at worse it will only hurt my ears), if it is an executable file, I should be especially carefull..
Putting the type attribute in the filename is the easiest way to tell this information reliably to the user, so let's use the KISS principle here!
Slashdot Mirror
>Why is it doubtful that the kernel comes into play?
Because BeOs proponents usually talked about their GUI subsystem, or the multithreaded design of their apps, not of their kernel, that's why I don't think that the kernel
>- Interactive patches (preempt, ll, et al)
I installed the intertactive patches on the 2.4 kernel and I didn't see any difference in the responsiveness of the applications.
>- IP QoS
Uh? We're talking about the responsiveness of X locally..
So IP has nothing to do with it..
Beside as we're talking about X, X is not ideal for remote connections, I believe that a higher level protocol with more things done in the server would be more responsive and use less bandwith..
> Alright, people need to listen closely. XFree86 is NOT SLOW, the toolkits you lay on top of it are what bogs it down.
So if you use a ugly looking desktop X is fast, but if you use a modern looking desktop X is slow, both with KDE and Gnome.
There are two possibilities:
- either KDE and Gnome are both slow
- or X itself is not well adaptated to modern needs, so we could say that X is slow.
BeOS feels much faster than KDE or Gnome, so it *is* possible to have a fast modern looking desktop, either it was because BeOS kernel was fast (doubtfull) or because it had a better GUI subsystem, or maybe because the apps were better designed..
>Because it wasn't in Apple's interests. Mac users are willing to pay Apple prices, so Apple has enormous profit margins.
But low volumes!
Low volume imply fewer software written for MacOS, so people won't buy Apple's computer because there are fewer software --> dwindling market share.
This is a vicious circle which has caused Apple to catter to niches where it was successfull.
But this niche strategy is fragile: it is quite easy to loose a niche (education has been lost), it is very difficult to build a "new niche".
Apple is lucky that Microsoft has ported its Office product otherwise they would be in an even worse situation..
The reasonning is:
:-)
1. the repartition of the e/e-bar annihlations follows the mass repartition, not the repartition of the visible matter.
2. they don't know what mechanism of ordinary matter could cause these e/e-bar annihlation, so they associate it with dark matter.
I agree that this second hypothesis seems a bit risky, but it doesn't seems unreasonnable too, so calling it a "miracle step" is a bit too far IMHO: by definitions miracles are unreasonnable
>*reboot* gentoo in under 30 seconds, INCLUDING X. What else do you want?
Having KDE running on top of X, and being logged on automatically and doing this under 10seconds?
BeOS was able to do it!
>I can safely say I could live comfortably there on less than $1000 US per year.
Yes, but only if you plan to stay forever in India!
How will you retire in the US if you cannot put aside enough money?
> I can't think of a single game that lets me choose between DirectX and OpenGL where I have chosen OpenGL over the dx.
IL2 Sturmovick is available both in OpenGL and in DirectX, but on my Radeon the OpenGL mode was much better than the DirectX.
>Microsoft originally *GOT* that monopoly how... a gift from God?
A gift of IBM actually, but I suppose that you could call IBM the "gods of computer" at that time..
>Our ongoing failure to connect all the dots of the various paradigms could indicate that he[Einstein] was on to something...
I'm afraid not: there is a famous "thought experiment" proposed by Einstein, Podolsky and Rosen which would "proove" that quantum mechanic is incomplete.
Alain Aspect turned this "thought experiment" into reality in the 80's and he found that reality didn't agree with Einstein!
Of course everybody agrees that quantum mechanic is not the full truth, that's why researchers comes with such weird things as string theories, but the thing is: reality don't comply with the way Einstein was thinking about it..
PS: this is not at all a criticism of Einstein, as I think that the EPR paradox is really really interesting, and weird also!
>True, programming errors can lead to crashes and security problems. But at least you can easily fix those.
(sarcasm) Yes, that's why all the apps that we have today are so secure! (/sarcasm)
As for the crash, if the crash is easily reproducible, yes it is easy to fix, but how about the misterious, non-reproducible crash, that happens only when the load is high, so only when your client DOESN'T want your app to crash?
It can be very,very hard to correct..
>>Yes, Python is much slower than C, but is-it too slow for the application considered or is-it fast enough?
>Who knows? Why take chances?
You'll copy me one thousand times: "premature optimisation is the root of all evil!"
Python or Ruby are easier to use, and faster to program with, if you find a performance problem then coding this part in C is usually not too hard..
Coding everything in C for a high-level app which should be doable in Python,Ruby or Java is premature optimisation..
> I don't want to use a decent editor, I want to use Vi!
Well use vim, then!
>Now that I've managed to piss off as many people as possible, why Python?
For these kind of apps, Python, Ruby or maybe Java would be the "better choice" really.
I prefer Ruby but many more people know Python, so IMHO Pyhon would be a logical choice.
>Doing it explicitly reduces the chances of nasty surprises later on [cut]
Well the nasty surprise you're talking about are in a GC environement: too much memory usage, bad performance.
When you do it by hand, a bad memory handling will usually cause crashes, security problems,etc..
I prefer the problems associated with the GC, thanks!
>Python is slow compared to C.
Yes, Python is much slower than C, but is-it too slow for the application considered or is-it fast enough?
Legal posturing from Trolltech?
Could you give a reference?
Qt/X11 is GPL, if wxWindows over Qt is GPL too then their wouldn't be any problem.
I don't think that a wxWindows could be LGPL if it was made above Qt, but I'm not sure..
> Most people that make any significant contributions to their field do so before they're 30.
Einstein's most significant contribution: generalised relativity, was made between 1912 and 1915, and he was born on 1879.
Which means when he was between 33 and 36 years old, yes he made other discory before he was 30 year old, but generalised relativity is really his "chef d'oeuvre" IMHO.
I had troubles making my hw works correctly:
- my mousewheel had problems!
- the sound never worked really correctly with multiple sounds at the same time..
- installing an ADSL USB modem was a pain: I needed to recompile a kernel: with a Celeron 333, it took a whole night! It took me three week-ends to make it work.
- the interface felt sluggish and ugly: but I've recently seen a PC with RedHat: the fonts are much better than they used to be.
Maybe all this was Mandrake faults, but all the "small modifications" needed to make Linux work correctly annoyed me and I went back to Windows (XP is stable enough for my need), and I am happily using Mozilla, Ruby, IrfanView (etc..) on it.
Now if I could have an XTerm and the Unix copy/paste style (with the mouse) working on WinXP, it would be wonderfull..
>Since Java's focus is the enterprise app servers
:it failed, Swing was (is still?) slowwww, buggy, leaky.
Strange, I could have sworn that Sun wanted to use Java *everywhere*:
- in the client
Each time I see a Java app, I can recognise it: it's slow and it looks awfull..
- in embedded stuff : the jury is still out here.
- in the web browser: it mostly failed, applets are rare.
So the enterprise app server is not THE focus of Java, it is just one of the domain where Java have not failed..
>The worst example is probably W3C XML Schema - the classical example of design by committe, hard to use,[cut]
Well, I don't know if the W3C XML Schema is good or not, but the "normal" DTD definition is really, really ugly!
I'm not sure if you're agreeing or desagreeing with me.
:= var_name; which is equivalent to say other_var: type_name; other_var = var_name;
Yes to create a new object you use !! in Eiffel, it could be better true but still its syntax is far more elegant than C++, no?
I think that the best syntax to create an object is in Limbo (a script language in Plan9), you can say:
var_name: type_name; as in Pascal but you can also say other_var
Nice, no? This way when you change the type of var_name, you change also the type of other_var..
> Enforced contracts + templates + multiple inheritance
Eiffel has all these feature with a nice syntax.
Eiffle do not have interface, but I don't see the difference between interfaces and abstract virtual base classes, when you have multiple inheritence.
Apparently, it is quite possible to have both GC and manual memory management: C# have it..
I like the idea of having GC by default (secure and easy to use) and still being able to manage memory "by hand" if there is a need.
Oh and I disagree that C++ *has* to be that complex: Eiffel has multiple-inheritence, templates,etc.. and its syntax is very nice..
>Speak for yourself, man -- my role model is Willow Rosenberg. Given that she is a fictional Jewish lesbian witch who almost ended the world, which
>doesn't really describe anything about me, that might be strange, but then again, she certainly ain't "stupid".
Yes, but Willow isn't the principal hero of the show: Buffy is!
And at first, Buffy wasn't very different of the "stupid blond" role model!
>Lightwave has a pipeline that's like 390 bits wide
According to their website, their full precision renderer use 128bits: 32 bits for each component (RGBA).
I doubt that the integer register are used that much for processing the pixels, so for processing reason the 64-bitness is not so much important.
On the other hand, for memory adressing the 64-bitness matter: I wouldn't be surprised that a process could use more that 4 GB to do the rendering..
And why don't you put you .doc files in the CVS repository?
If you're comparing CPU with the same ISA, maybe the MIPS is still interesting?
Otherwise of course, it means nothing!
I'm not sure if you disagree with me: what I said is that I am AGAINST having a type attribute inside a file.
Otherwise what prevents someone creating a file named foo.ogg with an attribute 'type=exe' inside?
Keeping the type in the filename is not a perfect defense of course, but the 'type within attribute' setup do not protect the user, it only makes the problem worse!
While I agree that using a uniform metadata system and a Plan9-like OS could be very insteresting, I think that the type should be kept within the filename (foo.ogg) instead of having a file foo with an attribute type=ogg inside.
Why? For the same reason, that we use name for files instead of numbers: it's easier for the users. If you embed the type inside an attribute, what happen if you have a file foo.ogg with an attribute type=exec ?
Lots of problems for the users!
The type attribute is special IMHO: it tells the users what this file will be used for.
If I download a file foo.ogg, I'm not especially carefull before activating it in my browser (at worse it will only hurt my ears), if it is an executable file, I should be especially carefull..
Putting the type attribute in the filename is the easiest way to tell this information reliably to the user, so let's use the KISS principle here!