Its wrong to have the most basic data type wobble over the bit length.
Most people dont think about this when writing their programs. This is a failure of C, because programming languages are for the people.
The solution would have been to have the basic data types with fixed size, and additional data types with "some size between 16 and 64 bit giving the optimal performance on the target machine".
This would have saved many people a lot of grief...
The only reason why Transmeta do the translation transparently is the instant support for the x86 OSes this gives.
For Java you dont need this. A full blown Java VM application gives better Java performance, because it basically does the same, but with less system-specific constraints.
>In C, an int is whatever size int is most easily handled by the target system
This is not a feature. Its a failure of the standardization process.
You cannot write portable programs if your basic data types are not defined.
And it also doesnt give todays hardware any advantage. Alpha uses 32 bit int. Using 64 bit would be pointless since portable programm wont use the added 32 bits.
>It's my belief that it should be possible to make a compiler generate much better code in the general case than someone writing hand coded assembler.
No. Hand coded assembler, coded by a clueful programmer, will always be better than compiler generated code. Or at least as long as a compiler cannot considered an advanced Artificial Intelligence...
To some large extent this is a question of creativity. Compilers are not creative.
for argument (1): Well, we are talking about a =clueful= programmer.
for argument (2): This isnt significant.
For the profiling: A clueful assembler programmer can do this too.
>If X = 100, that makes sense, but if X = 10,000 it doesn't. Or would you dynamically spawn more processes to handle greater and greater loads?
Not dynamically. Thats not needed.
Just use a fixed number of, lets say 20 processes that each handle five percent of the maximum load/number of connections.
No dynamic scaling necessary. The system doesnt need to be efficient in the low-load case. Only the efficiency for the maximum load case is of interest.
>Because the Java API does not include non-blocking read and write APIs, VolanoMark is implemented by using a pair of Java threads on each end (client and server) of each connection
Obviously broken.
Overload your system with an absurd and absolutely useless number of threads and then complain about the time the kernel spends in the scheduler. Idiotic...
Sun really should add this trivial non-blocking functionality. And bring Java out of the toy stage.
Yes, they point I wanted to make is that professionals want nice easy to use stuff, too!
UNIX: The original design was nice. But if you go on with a nice design for 30 years it gets pretty crufty. Just look around in your file system and in/etc and you should see what I mean.
For security: programs should not be allowed to access anything that is not their business. If any app goes wild it can trash my whole user directory. And if it is a service that for some trivial reason needs to run as root, you are dead. This is bad design.
Well, why do "trained professional" programmers demand integrated graphical development environments for they work? Why do most of them refuse to exclusively work with vi, some xterms, and some scripts?
But the user interface is not the main beef I have with UNIX. Its the flawed design and amount of chaos below that interface.
Microsoft had a chance to do a fresh start and create a new and well designed system. But, as we now, they didnt use that chance.
>It's not the design of Unix, nor security issues with both OS-es
I absolutely disagree. An example for the basic design flaw of UNIX may look like this: Why has a subsystem intended to deliver email the right to overwrite my partition table (or anything else)? Answer: It shouldnt have. It =automatically= shouldnt have.
The original design of UNIX wasnt tailored to security. Otherwise something like telnet never had existed (and people would have used SSH or similar instead...). There are numerous other examples. UNIX is a patchwork. A good design isnt patchwork.
design philosophies: Its easy: Both OSes serve the same purposes (run server and desktop applications, do this secure, stable, and easy to use). A design philosophy that doesnt lead to as system that flawlessly fulfils its purpose is a flawed design philosophy. Both are flawed, unfortunately.
>Unix takes years to master, but so does NT
Yes. But I believe that a good design wouldnt require this at all.
Administrating UNIX is no problem for =me=. But I do this for many years now, and I pity everybody that starts with this right now.
From a multi-billon dollar company you can expect well designed, ergonomic, secure, stable, and easy to use stuff. Unfortunately, the company in question doesnt deliver it (and I dont mean Red Hat).
From a bunch of loosely organized hobby programmers you cannot expect anything like that. Impressingly the stuff delivered by this bunch is superiour in many regards when compared to the things delivered by the specific multi-billion dollar company.
Still, it is a mistake to lie to people about Linux. Linux is not easy. Not to use, not to administrate. This will improve. But it isnt now.
And people should be aware of this before they try it.
I personally was, but I started with kernel 1.2, anyway.
"Linux is much easier to administrate, you only need to dive deeply into the good old unix cruft to get it (3 or 4 years should be completely sufficient)."
Not so good, isnt it?
"Linux is inherently insecure due to the flawed security design of UNIX, which it clones. But it at least it can be more secure than Windows 2000, which is even worse. Of course, to get superior security, you need to learn about UNIX, but 3 to 4 years... (we already had that)"
Not really good for marketing, unfortunately.
"You only need to apply 20 or so security fixes to your distribution and look at bugtraq with argus eyes, and with some luck you may not get cracked!"
Oh, no, please.
"While admittedly setting up and administrating anything non-trivial on UNIX is pure hell for any beginner, it will be much more stable than anything Windows. If the poor admin didnt give up. (And...blabla... security fixes...blabla... bugtraq...blabla... he may not get cracked)."
Well, it IS much more stable. Still... suppose the marketing people need something better to promote Linux...
Anyway. Please be honest: Do you REALLY want to send all that poor Windows people into UNIX hell? And tell them that Linux/UNIX WILL make them happy?
I dont. How about this: With Windows X you are using a crappy system from a company that repeatedly has proven to be unable to deliver good stuff. If you switch to Linux you =can= get a more stable and secure system. But keep in mind that UNIX is not designed for easy administration. For beginners its pure hell. The UNIX design is 30 years old and flawed. For security its deeply flawed. But unfortunately still the best this poor planet has.
(moderators: moderate this down, please, it lacks expression of popular opinion.)
>Thought the biggest network improvement (from my current experience ) is minimize data packet transmission necessity itself as much as possible.
Agreed. The original Q1 "dumb terminal" concept wasnt much of a hit. Q3 is pretty good now, but possibly not good enough if voice or whatever needs to be added (or if many players are visible).
Seems that client and server should be symmetric, with basically the same high level abilities, allowing the client to operate with a minimum number of "high level hints" provided by the server. This breaks any quake-like client/server architecture, however.
progressive layer of abstractions: sounds like a hell to implement. Maybe a single but scalable layer does it just as well, squeezed into available bandwidth by sorting objects for estimated error of client side simulation, and stripping low priority objects until it fits. Or whatever...
Anyway, I hope you survive the nitty gritty stuff well, and I look forward to seeing your engine in 3DRealms future games!
>Not too experimental, had all the R&D fun now, am knee deep in nitty gritty of rounding implementation of "all the other stuff".... though still all by my (happy) lonesome
Impressive, Im looking forward to the next 3DRealms engine. The annoying aspect with that rounding stuff however is that it usually turns out to be the larger part of the work...
Of course you shouldnt underestimate the networking thing, Carmack needed four games to get that right, and Sweeney needed many betas.
Some (possibly redundant) hints for UDP:
- bandwidth is king, for analog modems - if you overload modem bandwidth, you get some nice +1000 ms ping (queueing, same for ISDN) - modems tend to "resync" pretty often if they are unsure about connection quality (e.g. the connection regularly is gone for 5 secs, and the queues fill up like hell) - the 28+2/UDP+PPP byte packet overhead is annoying, again for analog modems - cable modems often seem to have terrible packet loss (seems to be a "broadcast and hope that it doesnt collide and just drop it if it does" principle) - dynamic bandwidth estimation is much fun (which perhaps is the reason why Q3 and others let the user set it as a static value). You may want to go for the receivers end if you want to try this. - pps needs to be constant and independent of fps - "Power Play" wont give any advantage for non-analog users if the ISP has headroom on his subnet and the server is located in that subnet (except for very minor UDP header compression advantage)
In April 1998, Alabama passed an addition to the obscenity statute of the state law that "makes it unlawful to produce, distribute or otherwise sell sexual devices that are marketed primarily for the stimulation of human genital organs." Part of a bigger bill restricting licenses for strip clubs, the law argues that these sex toys are obscene and appeal to a "prurient interest."
and even more interesting:
There is, the Alabama officials wrote, "no fundamental right to purchase a product to use in pursuit of having an orgasm." What they should have written is that women have no fundamental right to purchase a product to use in pursuit of having an orgasm. Because while those veined, flesh-colored pseudo-penises are not legal, those displays of crotchless panties -- not to mention Viagra -- are perfectly OK.
Slashdot Mirror
ok, admitted, only a user account crack.
Which however works well.
There are some messages here with links that send your slashdot pw to any site when clicked...
Looks like the Advisory wasnt irresponsible at all.
Despite the fact that such exploits are trivial indeed. In hindsight, at least.
...bot!
Thanx.
Doesnt look too good unfortunately...
Its wrong to have the most basic data type wobble over the bit length.
Most people dont think about this when writing their programs. This is a failure of C, because programming languages are for the people.
The solution would have been to have the basic data types with fixed size, and additional data types with "some size between 16 and 64 bit giving the optimal performance on the target machine".
This would have saved many people a lot of grief...
Does anyone know about such a comparison?
Or, alternatively one between STL and Suns collection classes?
This would be very interesting and helpful, since this may be the only roadblock for using Java in a critical project right now.
If anyone has an URL, please put it in an answer to this post.
The only reason why Transmeta do the translation transparently is the instant support for the x86 OSes this gives.
For Java you dont need this. A full blown Java VM application gives better Java performance, because it basically does the same, but with less system-specific constraints.
>In C, an int is whatever size int is most easily handled by the target system
This is not a feature. Its a failure of the standardization process.
You cannot write portable programs if your basic data types are not defined.
And it also doesnt give todays hardware any advantage. Alpha uses 32 bit int. Using 64 bit would be pointless since portable programm wont use the added 32 bits.
>It's my belief that it should be possible to make a compiler generate much better code in the general case than someone writing hand coded assembler.
No. Hand coded assembler, coded by a clueful programmer, will always be better than compiler generated code. Or at least as long as a compiler cannot considered an advanced Artificial Intelligence...
To some large extent this is a question of creativity. Compilers are not creative.
for argument (1): Well, we are talking about a =clueful= programmer.
for argument (2): This isnt significant.
For the profiling: A clueful assembler programmer can do this too.
>If X = 100, that makes sense, but if X = 10,000 it doesn't. Or would you dynamically spawn more processes to handle greater and greater loads?
Not dynamically. Thats not needed.
Just use a fixed number of, lets say 20 processes that each handle five percent of the maximum load/number of connections.
No dynamic scaling necessary. The system doesnt need to be efficient in the low-load case. Only the efficiency for the maximum load case is of interest.
>Because the Java API does not include non-blocking read and write APIs, VolanoMark is implemented by using a pair of Java threads on each end (client and server) of each connection
Obviously broken.
Overload your system with an absurd and absolutely useless number of threads and then complain about the time the kernel spends in the scheduler. Idiotic...
Sun really should add this trivial non-blocking functionality. And bring Java out of the toy stage.
>There are IDEs for Linux.
/etc and you should see what I mean.
Yes, they point I wanted to make is that professionals want nice easy to use stuff, too!
UNIX: The original design was nice. But if you go on with a nice design for 30 years it gets pretty crufty. Just look around in your file system and in
For security: programs should not be allowed to access anything that is not their business. If any app goes wild it can trash my whole user directory. And if it is a service that for some trivial reason needs to run as root, you are dead. This is bad design.
Well, why do "trained professional" programmers demand integrated graphical development environments for they work? Why do most of them refuse to exclusively work with vi, some xterms, and some scripts?
But the user interface is not the main beef I have with UNIX. Its the flawed design and amount of chaos below that interface.
Microsoft had a chance to do a fresh start and create a new and well designed system. But, as we now, they didnt use that chance.
>It's not the design of Unix, nor security issues with both OS-es
I absolutely disagree. An example for the basic design flaw of UNIX may look like this:
Why has a subsystem intended to deliver email the right to overwrite my partition table (or anything else)?
Answer: It shouldnt have. It =automatically= shouldnt have.
The original design of UNIX wasnt tailored to security. Otherwise something like telnet never had existed (and people would have used SSH or similar instead...). There are numerous other examples. UNIX is a patchwork. A good design isnt patchwork.
design philosophies:
Its easy: Both OSes serve the same purposes (run server and desktop applications, do this secure, stable, and easy to use). A design philosophy that doesnt lead to as system that flawlessly fulfils its purpose is a flawed design philosophy. Both are flawed, unfortunately.
>Unix takes years to master, but so does NT
Yes. But I believe that a good design wouldnt require this at all.
Administrating UNIX is no problem for =me=. But I do this for many years now, and I pity everybody that starts with this right now.
From a multi-billon dollar company you can expect well designed, ergonomic, secure, stable, and easy to use stuff. Unfortunately, the company in question doesnt deliver it (and I dont mean Red Hat).
From a bunch of loosely organized hobby programmers you cannot expect anything like that.
Impressingly the stuff delivered by this bunch is superiour in many regards when compared to the things delivered by the specific multi-billion dollar company.
Still, it is a mistake to lie to people about Linux. Linux is not easy. Not to use, not to administrate. This will improve. But it isnt now.
And people should be aware of this before they try it.
I personally was, but I started with kernel 1.2, anyway.
Its a very simple secret:
Technology that is difficult and complicated to operate is inferior technology.
Oh, and of course: Technology that shows you nice hip windows and is easy to operate but doesnt work well is an even more inferior technology.
I personally know how to administrate UNIX. But I also see its shortcomings. If you dont, you may be blind.
"Linux is much easier to administrate, you only need to dive deeply into the good old unix cruft to get it (3 or 4 years should be completely sufficient)."
...blabla ... security fixes ...blabla ... bugtraq ...blabla... he may not get cracked)."
Not so good, isnt it?
"Linux is inherently insecure due to the flawed security design of UNIX, which it clones. But it at least it can be more secure than Windows 2000, which is even worse. Of course, to get superior security, you need to learn about UNIX, but 3 to 4 years... (we already had that)"
Not really good for marketing, unfortunately.
"You only need to apply 20 or so security fixes to your distribution and look at bugtraq with argus eyes, and with some luck you may not get cracked!"
Oh, no, please.
"While admittedly setting up and administrating anything non-trivial on UNIX is pure hell for any beginner, it will be much more stable than anything Windows. If the poor admin didnt give up. (And
Well, it IS much more stable. Still... suppose the marketing people need something better to promote Linux...
Anyway. Please be honest:
Do you REALLY want to send all that poor Windows people into UNIX hell? And tell them that Linux/UNIX WILL make them happy?
I dont. How about this:
With Windows X you are using a crappy system from a company that repeatedly has proven to be unable to deliver good stuff. If you switch to Linux you =can= get a more stable and secure system. But keep in mind that UNIX is not designed for easy administration. For beginners its pure hell. The UNIX design is 30 years old and flawed. For security its deeply flawed. But unfortunately still the best this poor planet has.
(moderators: moderate this down, please, it lacks expression of popular opinion.)
>Thought the biggest network improvement (from my current experience ) is minimize data packet transmission necessity itself as much as possible.
Agreed.
The original Q1 "dumb terminal" concept wasnt much of a hit. Q3 is pretty good now, but possibly not good enough if voice or whatever needs to be added (or if many players are visible).
Seems that client and server should be symmetric, with basically the same high level abilities, allowing the client to operate with a minimum number of "high level hints" provided by the server. This breaks any quake-like client/server architecture, however.
progressive layer of abstractions:
sounds like a hell to implement. Maybe a single but scalable layer does it just as well, squeezed into available bandwidth by sorting objects for estimated error of client side simulation, and stripping low priority objects until it fits. Or whatever...
Anyway, I hope you survive the nitty gritty stuff well, and I look forward to seeing your engine in 3DRealms future games!
>Not too experimental, had all the R&D fun now, am knee deep in nitty gritty of rounding implementation of "all the other stuff" .... though still all by my (happy) lonesome
Impressive, Im looking forward to the next 3DRealms engine.
The annoying aspect with that rounding stuff however is that it usually turns out to be the larger part of the work...
Of course you shouldnt underestimate the networking thing, Carmack needed four games to get that right, and Sweeney needed many betas.
Some (possibly redundant) hints for UDP:
- bandwidth is king, for analog modems
- if you overload modem bandwidth, you get some nice +1000 ms ping (queueing, same for ISDN)
- modems tend to "resync" pretty often if they are unsure about connection quality (e.g. the connection regularly is gone for 5 secs, and the queues fill up like hell)
- the 28+2/UDP+PPP byte packet overhead is annoying, again for analog modems
- cable modems often seem to have terrible packet loss (seems to be a "broadcast and hope that it doesnt collide and just drop it if it does" principle)
- dynamic bandwidth estimation is much fun (which perhaps is the reason why Q3 and others let the user set it as a static value). You may want to go for the receivers end if you want to try this.
- pps needs to be constant and independent of fps
- "Power Play" wont give any advantage for non-analog users if the ISP has headroom on his subnet and the server is located in that subnet (except for very minor UDP header compression advantage)
>I am coding to UDP right now, and am perfectly happy
hm... lending a hand for a known project or experimental stuff for future ones?
admitted, Im overly curious...
checking again I found that the salon article is about a year old, therefore obviously a little outdated.
So theres still hope... (for female orgasm in Alabama, at least).
Legal marriage of 13 year olds, however, reminds again of the Middle Ages. Well, perhaps Im nitpicking...
from www.salon.com:
2 5feature.html)
In April 1998, Alabama passed an addition to the obscenity statute of the state law that "makes it unlawful to produce, distribute or otherwise sell sexual devices that are marketed primarily for the stimulation of human genital organs." Part of a bigger bill restricting licenses for strip clubs, the law argues that these sex toys are obscene and appeal to a "prurient interest."
and even more interesting:
There is, the Alabama officials wrote, "no fundamental right to purchase a product to use in pursuit of having an orgasm." What they should have written is that women have no fundamental right to purchase a product to use in pursuit of having an orgasm. Because while those veined, flesh-colored pseudo-penises are not legal, those displays of crotchless panties -- not to mention Viagra -- are perfectly OK.
(http://www.salon.com/urge/feature/1999/02/cov_
I really feel sorry for all sensible Americans for living in a country that repeatedly makes a complete fool of itself.
On the other hand, the Australians suffer a lot, too lately...
now we need a quad 1GHz Athlon system with dual channel DDR PC133. 4GB/s.
Why did you do this?
Now the poor guy will have endless nightmares
(and wake up in the night, covered with cold sweat, mumbling "msd...ooos")!
>What kind of kernel does bad ol' Windows have?
Well, it doesnt have a kernel.
Where other systems have a kernel, it has =something=.
You really dont want to know, what =something= is.
And forget about your question! Such questions are dangerous!
>I have a dream... that all computers will not be judged by the clock speed of thier processors, but by the file system of thier hard drive.
If you still like that dream, then reiserfs may send you directly to heaven...
And save you an investment into Intel or AMD.