I second that. Any person who would make an accusation like that has very little experience programming. SkyOS probably catches Linux kernel calls and redirects them to the SkyOS kernel. I think the SkyOS team deserves an apology.
I find the attitude of Slashdot readers perplexing, especially their attitudes toward operating systems that are not Linux. Linux fails as an operating system on many levels. It is open source and free, but its implementation and architecture are very mediocre.
As long as there is room for a better operating system, people should be making a better operating system.
A 10-stage pipeline doesn't necessarily sound like a good thing. Maybe this allows more sophisticated microcode. In that case, they seem to be going backward as far as RISC goes. And if there is a branch mispredict will the processor have to refill the WHOLE pipeline before executing instructions again? Now if there were 4 separate pairable 5-stage pipelines, then I think we'd have something.:)
Last few years? Hmm. Virus kits have been around for awhile now. Right now I am looking over the docs for IVP (Instant Virus Production Kit) 1.7 which has a time-stamp from 1992. It supported.COM/.EXE(MZ) infections, encryption, etc. If you look through a virus bestiary, all of these viruses begin with IVP.*. I remember seeing a "review" of the kit by a virus software company, calling it shoddy. So I guess Virus Kits are nothing new. Just thought I would mention it.
Re:Yes, you are not 100% correct.
on
MenuetOS Debuts
·
· Score: 1
> Why on earth would anyone bother hand-optimizing a piece of code that spends probably 99% of its time blocking on disk I/O?
And by that same method of thinking, you must believe that Word doesn't need to be optimized because 99% of the time it is blinking a stationary cursor.
> And how exactly is it "portable"?
I mentioned the site http://www.linuxassembly.org/ They will explain to you how it is portable. It is not portable across hardware platforms, but software platforms. This is done by using a macro library that inlines kernel calls.
> Your time is your own and if you want to waste it that's your problem, but this is hardly something to be bragging about.
It's not mine and I'm not bragging about it. Besides, this is just a matter of opinion. I would gladly use a 350-instruction cp replacement.
Re:Yes, you are not 100% correct.
on
MenuetOS Debuts
·
· Score: 1
> That is, if you tend to have one bug per 50 lines of code (let's say), it doesn't matter if the code is ASM, C, Java, SQL, or Bourne Shell Script. Imagine how many lines of ASM it would take to be equivalent to cp file1 file2?
The source on linuxassembly.org gives a portable (BSD/*nix/BeOS) cp that is roughly 350 lines. So that's 7 errors accordingly to that rule. Each of which was probably fairly easy to track down. The end result: very small, fast, portable, beautiful.:) Worth it? Yes!
You are not 100% correct either.
on
MenuetOS Debuts
·
· Score: 1
You are far from 100% correct too, but I will forgive you because your post wasn't nearly as condescending as his.:)
Yes, there are more "failure modes" in a low level language than a high level language, but that is a simple trade-off for more control.
As with any language, if you know what you are doing, you are less likely to make errors. If you have a high degree of control, it does not necessarily mean you will make proportionately more errors if you know what you are doing.
To be honest, I find it easier to debug an ASM program. You write the code, you know what precisely what is going on. And the capability of C compilers compared to ASM programmers is over-exaggerated. I have seen well-written C code approach novice written ASM code. C compilers can (depending on the programmer) generate some really impressive, logical, clean code - but not usually something that can compete with an ASM programmer.
I fail to see the reasoning behind your post. It makes absolutely no sense. Why would an operating system implemented ASM be any lesser than an operating system implemented in a high-level language?
The only negative aspects of ASM involve production time and portability. Well, he obviously over came "production time" and portability might not be a concern. So the operating system will inherit all of the positive aspects of ASM such as speed, size, and readability (yes, I'm not joking).
So then, what about ASM invalidates Menuet?
LLL vs HLL, Menuet vs World
on
MenuetOS Debuts
·
· Score: 2, Insightful
MenuetOS has been floating around for a while now. I briefly looked at the website a while ago, it looks tres cool, but I don't know much about it. Even without knowing the details, I can say that for a hobby project, this is a staggering accomplishment. As well, there other operating systems in development that are 100% ASM, Unununium comes to mind. http://uuu.sourceforge.net/
The fact that the operating system was made in ASM is bringing up the low-level language versus high-level language war. I will admit that Linux and MenuetOS aren't really comparable. But ignoring differences, the end result: MenuetOS makes Linux look MEGA bloated, slow, and laughable. You guys should be taking 2nd, 3rd, and 4th looks at QNX RTP, BeOS, and AtheOS. This should serve as a big kick in the ass for you all Linux-fans. It's really nothing "that great." Sure it's free, but you sacrificed quality.
People claim that C compilers can generate code that is similar to what an ASM programmer is capable of. This is not true. A well-planned and pain-stakingly optimized C program can approach a novice ASM programmer. But this is almost never the case. Plus, there is also the inherent "beauty" of well-designed ASM code that most high level languages will never reproduce.
Anyway, I could go on forever. If you want to address anything I said, I am ready prepared for retaliation.:)
Why does Intel insist on sucking Microsoft's ass? Intel has given Microsoft the opportunity of having Windows ready for the launch of IA64, at their expense. This could have been an opportunity to lessen Microsoft's grip over the next generation of computers.
If a quality operating system (which are abundant for IA32) could have been produced for IA64 before Windows was, it would have made a huge dent in the Windows IA64 market share.
Developers eager to develop IA64 applications would use the first operating system available. Initially, there would be more software available for the first operating system out the gate. And people would recognize the first operating system as "the" native operating system. The implications are obvious.
Also, I have a feeling Intel will focus IA64 for on servers and stuff like that. I don't think the average person will be using this on their home for a long time. Which would be another mistake because it would lower the chances of widespread adoption. If that happens, let's hope we're using 64-bit processors in our homes by 2020.:)
Honestly, I am still way way more interested in Alpha. (The "server focus" mistake is ongoing.) I hope they are able to continue supporting it.
Someone on Slashdot has recommended Forth to me as "perfect middle ground between ASM and C." I have looked at the FAQs and could not find a quick-and-dirty overview of the language.
I am looking for the simplicity, control, and elegance of ASM. But I also would like to enjoy some degree of abstraction and features that reduce the drudgery of programming. I have looked at HLA and Terse but they are platform-dependent, unless I write my own compiler. Do you think Forth meets these criteria?
Another thing. Just from peeking at the FAQ I see Forth uses postfix expressions (among other things), which seems a little dated. I assume this was implemented for compiling on resource-constrained machines? Do you plan on giving Forth a minor face-lift?
I was a victim of the "terminate access now - ask questions later" policy. My ISP terminated my account without contacting me first. Honestly, the reasons why don't really relate to anything being discussed here, but it's still the same problem.
Eventually I convinced my ISP to reconnect my service. This involved jumping through a lot hoops because of the internal bureaucracy of the company. And my connection never was restored.
I was treated like crap by the staff. They screwed up many, many times. Nobody would take responsibility for the actions of the company. They recorded my conversations. Everyone kept passing the buck; I was an object of a departmental ping-pong game.
So I decided to take them to court. I am doing this, not because I'm greedy, but to shovel that same shit down their throats. Even if I lose I've already wasted hundreds of their dollars on lawyers. I guess I have a strong case, but it's hard to beat a lawyer at his own game.
I can't get detailed for obvious reasons. But there is a moral to the story: read the contract and the terms of service.
If the terms of service is longer than a page, screw them. Companies that have a huge contract & terms of service are not trying to "protect" themselves; they are trying to waive their "responsibilities." Avoid these kinds of companies like the plague.
Now I am with a new ISP. They have a contract & terms of service which protects them. They can terminate my account if I *violate* the terms of service. But they can't terminate my account if they *suspect* I violated the terms of service. Way better!
1) It is as platform dependant as any language can possibly get.
Sort of. Assembly is hardware dependent but not necessarily software dependent, thanks to the standard use of ELF. In fact, if you write your Assembly programs properly they can easily be recompiled for any POSIX operating system (Linux, QNX RTP, BeOS) with absolutely no change, and Windows (all varieties) with MinGW if you do some tweaking.
There are some very nice hardware platforms out there. Especially Alpha, and it makes me said to alienate these. But, as you may know, most processors out there today are IA32 compatible. Even though Alpha is so nice. *sniff*
2) It is very hard to read.
This is strictly opinion. I find C hard to read. Assembly is simple, linear, and straightforward. You never have to guess what is going on. As for C, well, look at the obfuscated C contest.:)
3) It is relatively hard to learn. Don't tell me assembly isn't hard, it is definetely _MUCH_ harder than Ruby which has e.g. those nice and _easy_ string manipulation possibilities.
I am going to go against what you said. Assembly isn't hard. It is much easier to learn than most high-level languages. The basic instruction set is very small. Once you learn the basic instruction set the only thing you need to learn is how the hardware operates. That is the hard part.
Now with comprehensive driver systems in modern operating systems it is not necessary to learn all the gory details of the computer hardware. You just CALL any functions you need. Of course learning the gory details is always fun, if you wanna learn them.
4) Source code is huge.
Sort of. This is not true if you do things right. This kind of ties in with the last statement. Back in the cave-days most Assemblers were really unsophisticated. You wrote your program from beginning to end in ASM code with some labels. Maybe did some calls, jump around a bit.
Now a-days, we have come a long way. We are much more civilized. No ASM programmer likes to manually push 5 offsets on to the stack to perform a call. We use macros for all the "drudgery" that normally makes ASM programming hard work; especially chores that can't be optimized but are done often.
And for "meat" of the program you will find that ASM programming is a lot more satisfying. Most C optimizations are compiler dependent and it's hard to see what's going behind the scenes. In ASM you will always know if your ASM code sucks or not, before it's even done.
...a job done quickly, assembly is really not the language to use.
True enough! But once you have a solid code foundation it is pretty easy and quick to use.
I'd say this the other way arround: Assembly is a way to represent the raw binary format of 1's and 0's in a sort of human readable format.
I have to say that I have never really seen a highly optimizing HLL compiler ever beat an intermediate Assembly programmer. It is true for an architecture like Alpha, Assembly becomes less important.
But for IA-64... I remember reading through some of the IA-64 specs and it looks like low-level programming becomes even more important. This is coming from memory (and I'm running on 4 kb), but I recall Intel even saying on their pages that it is difficult to optimize for this platform. There are even more rules, special cases, and so forth.
It's a pretty unusual architecture and I don't think any compilers would be able to output really tight code without a total back-end rewrite. A compiler, even optimized for IA-64, would have a harder time beating an Assembly programmer because of this. But once you get "into the groove" looks like it could be pretty nice.
Like I said, this is all coming from memory so I can't cite specific documents. But if anyone else would like to prove me otherwise (and I *hope* somebody does), please post a reply. I really look forward to working with 128 general purpose registers one day!
In all honestly, I think Intel should have scrapped IA-64 completely and adopted Alpha as its next platform. Backwards compatibility is killing them!
This is my perspective: I am not running a server to handle hundreds of "default.ida" GET requests. These requests are a violation of my bandwidth and processing time.
Admittedly the resources required to handle the requests are small, it does not change the principal. Assuming our laws are "ethical," one has to admit vandalism and trespassing do not always go unpunished.
But one thing really perplexes me. Code Red has been in the media spotlight for weeks (?) now and it still runs rampant. What will it take to get these people to get off of their fat asses and fix their servers?
Forgive my ignorance on this issue, but would it be possible to send back a bogus "default.ida" that will ruin their setup? What is this file anyway?
This is the best solution. The lazy-ass who is administering the server will be punished, it will draw attention to the problem, and may prevent further intrusions until the problem is fixed.
I hate to break it to you, but this thing isn't running Linux. It's running QNX RTP which is a helluvalot better than that slow bloated dung pile Linux. So please don't add insult to injury by calling it that!
Some quick notes I made from a few links and about 2 minutes of reading:
- The fact that Audrey is 'hackable' is probably 3Com's (Audrey's makers) fault and not QSSL's (QNX's makers) fault. 3Com designed and packaged the system.
- If they used BeIA, Windows CE (or whatever) using the same design, it would be equally as easy to 'hack.'
- Doing this hack requires an Audrey flash ROM image. Something that is not widely available. So, unless you have connections like this guy did, it's probably not very easy to do.
Slashdot Mirror
I second that. Any person who would make an accusation like that has very little experience programming. SkyOS probably catches Linux kernel calls and redirects them to the SkyOS kernel. I think the SkyOS team deserves an apology.
I find the attitude of Slashdot readers perplexing, especially their attitudes toward operating systems that are not Linux. Linux fails as an operating system on many levels. It is open source and free, but its implementation and architecture are very mediocre.
As long as there is room for a better operating system, people should be making a better operating system.
A 10-stage pipeline doesn't necessarily sound like a good thing. Maybe this allows more sophisticated microcode. In that case, they seem to be going backward as far as RISC goes. And if there is a branch mispredict will the processor have to refill the WHOLE pipeline before executing instructions again? Now if there were 4 separate pairable 5-stage pipelines, then I think we'd have something. :)
Last few years? Hmm. Virus kits have been around for awhile now. Right now I am looking over the docs for IVP (Instant Virus Production Kit) 1.7 which has a time-stamp from 1992. It supported .COM/.EXE(MZ) infections, encryption, etc. If you look through a virus bestiary, all of these viruses begin with IVP.*. I remember seeing a "review" of the kit by a virus software company, calling it shoddy. So I guess Virus Kits are nothing new. Just thought I would mention it.
> Why on earth would anyone bother hand-optimizing a piece of code that spends probably 99% of its time blocking on disk I/O?
And by that same method of thinking, you must believe that Word doesn't need to be optimized because 99% of the time it is blinking a stationary cursor.
> And how exactly is it "portable"?
I mentioned the site http://www.linuxassembly.org/ They will explain to you how it is portable. It is not portable across hardware platforms, but software platforms. This is done by using a macro library that inlines kernel calls.
> Your time is your own and if you want to waste it that's your problem, but this is hardly something to be bragging about.
It's not mine and I'm not bragging about it. Besides, this is just a matter of opinion. I would gladly use a 350-instruction cp replacement.
> That is, if you tend to have one bug per 50 lines of code (let's say), it doesn't matter if the code is ASM, C, Java, SQL, or Bourne Shell Script. Imagine how many lines of ASM it would take to be equivalent to cp file1 file2?
:) Worth it? Yes!
The source on linuxassembly.org gives a portable (BSD/*nix/BeOS) cp that is roughly 350 lines. So that's 7 errors accordingly to that rule. Each of which was probably fairly easy to track down. The end result: very small, fast, portable, beautiful.
You are far from 100% correct too, but I will forgive you because your post wasn't nearly as condescending as his. :)
Yes, there are more "failure modes" in a low level language than a high level language, but that is a simple trade-off for more control.
As with any language, if you know what you are doing, you are less likely to make errors. If you have a high degree of control, it does not necessarily mean you will make proportionately more errors if you know what you are doing.
To be honest, I find it easier to debug an ASM program. You write the code, you know what precisely what is going on. And the capability of C compilers compared to ASM programmers is over-exaggerated. I have seen well-written C code approach novice written ASM code. C compilers can (depending on the programmer) generate some really impressive, logical, clean code - but not usually something that can compete with an ASM programmer.
I fail to see the reasoning behind your post. It makes absolutely no sense. Why would an operating system implemented ASM be any lesser than an operating system implemented in a high-level language?
The only negative aspects of ASM involve production time and portability. Well, he obviously over came "production time" and portability might not be a concern. So the operating system will inherit all of the positive aspects of ASM such as speed, size, and readability (yes, I'm not joking).
So then, what about ASM invalidates Menuet?
MenuetOS has been floating around for a while now. I briefly looked at the website a while ago, it looks tres cool, but I don't know much about it. Even without knowing the details, I can say that for a hobby project, this is a staggering accomplishment. As well, there other operating systems in development that are 100% ASM, Unununium comes to mind. http://uuu.sourceforge.net/
:)
The fact that the operating system was made in ASM is bringing up the low-level language versus high-level language war. I will admit that Linux and MenuetOS aren't really comparable. But ignoring differences, the end result: MenuetOS makes Linux look MEGA bloated, slow, and laughable. You guys should be taking 2nd, 3rd, and 4th looks at QNX RTP, BeOS, and AtheOS. This should serve as a big kick in the ass for you all Linux-fans. It's really nothing "that great." Sure it's free, but you sacrificed quality.
People claim that C compilers can generate code that is similar to what an ASM programmer is capable of. This is not true. A well-planned and pain-stakingly optimized C program can approach a novice ASM programmer. But this is almost never the case. Plus, there is also the inherent "beauty" of well-designed ASM code that most high level languages will never reproduce.
Anyway, I could go on forever. If you want to address anything I said, I am ready prepared for retaliation.
If a quality operating system (which are abundant for IA32) could have been produced for IA64 before Windows was, it would have made a huge dent in the Windows IA64 market share.
Developers eager to develop IA64 applications would use the first operating system available. Initially, there would be more software available for the first operating system out the gate. And people would recognize the first operating system as "the" native operating system. The implications are obvious.
Also, I have a feeling Intel will focus IA64 for on servers and stuff like that. I don't think the average person will be using this on their home for a long time. Which would be another mistake because it would lower the chances of widespread adoption. If that happens, let's hope we're using 64-bit processors in our homes by 2020. :)
Honestly, I am still way way more interested in Alpha. (The "server focus" mistake is ongoing.) I hope they are able to continue supporting it.
Someone on Slashdot has recommended Forth to me as "perfect middle ground between ASM and C." I have looked at the FAQs and could not find a quick-and-dirty overview of the language.
I am looking for the simplicity, control, and elegance of ASM. But I also would like to enjoy some degree of abstraction and features that reduce the drudgery of programming. I have looked at HLA and Terse but they are platform-dependent, unless I write my own compiler. Do you think Forth meets these criteria?
Another thing. Just from peeking at the FAQ I see Forth uses postfix expressions (among other things), which seems a little dated. I assume this was implemented for compiling on resource-constrained machines? Do you plan on giving Forth a minor face-lift?
I was a victim of the "terminate access now - ask questions later" policy. My ISP terminated my account without contacting me first. Honestly, the reasons why don't really relate to anything being discussed here, but it's still the same problem.
Eventually I convinced my ISP to reconnect my service. This involved jumping through a lot hoops because of the internal bureaucracy of the company. And my connection never was restored.
I was treated like crap by the staff. They screwed up many, many times. Nobody would take responsibility for the actions of the company. They recorded my conversations. Everyone kept passing the buck; I was an object of a departmental ping-pong game.
So I decided to take them to court. I am doing this, not because I'm greedy, but to shovel that same shit down their throats. Even if I lose I've already wasted hundreds of their dollars on lawyers. I guess I have a strong case, but it's hard to beat a lawyer at his own game.
I can't get detailed for obvious reasons. But there is a moral to the story: read the contract and the terms of service.
If the terms of service is longer than a page, screw them. Companies that have a huge contract & terms of service are not trying to "protect" themselves; they are trying to waive their "responsibilities." Avoid these kinds of companies like the plague.
Now I am with a new ISP. They have a contract & terms of service which protects them. They can terminate my account if I *violate* the terms of service. But they can't terminate my account if they *suspect* I violated the terms of service. Way better!
Sort of. Assembly is hardware dependent but not necessarily software dependent, thanks to the standard use of ELF. In fact, if you write your Assembly programs properly they can easily be recompiled for any POSIX operating system (Linux, QNX RTP, BeOS) with absolutely no change, and Windows (all varieties) with MinGW if you do some tweaking.
There are some very nice hardware platforms out there. Especially Alpha, and it makes me said to alienate these. But, as you may know, most processors out there today are IA32 compatible. Even though Alpha is so nice. *sniff*
2) It is very hard to read.
This is strictly opinion. I find C hard to read. Assembly is simple, linear, and straightforward. You never have to guess what is going on. As for C, well, look at the obfuscated C contest. :)
3) It is relatively hard to learn. Don't tell me assembly isn't hard, it is definetely _MUCH_ harder than Ruby which has e.g. those nice and _easy_ string manipulation possibilities.
I am going to go against what you said. Assembly isn't hard. It is much easier to learn than most high-level languages. The basic instruction set is very small. Once you learn the basic instruction set the only thing you need to learn is how the hardware operates. That is the hard part.
Now with comprehensive driver systems in modern operating systems it is not necessary to learn all the gory details of the computer hardware. You just CALL any functions you need. Of course learning the gory details is always fun, if you wanna learn them.
4) Source code is huge.
Sort of. This is not true if you do things right. This kind of ties in with the last statement. Back in the cave-days most Assemblers were really unsophisticated. You wrote your program from beginning to end in ASM code with some labels. Maybe did some calls, jump around a bit.
Now a-days, we have come a long way. We are much more civilized. No ASM programmer likes to manually push 5 offsets on to the stack to perform a call. We use macros for all the "drudgery" that normally makes ASM programming hard work; especially chores that can't be optimized but are done often.
And for "meat" of the program you will find that ASM programming is a lot more satisfying. Most C optimizations are compiler dependent and it's hard to see what's going behind the scenes. In ASM you will always know if your ASM code sucks or not, before it's even done.
True enough! But once you have a solid code foundation it is pretty easy and quick to use.
I'd say this the other way arround: Assembly is a way to represent the raw binary format of 1's and 0's in a sort of human readable format.
Precisely!
I have to say that I have never really seen a highly optimizing HLL compiler ever beat an intermediate Assembly programmer. It is true for an architecture like Alpha, Assembly becomes less important.
But for IA-64... I remember reading through some of the IA-64 specs and it looks like low-level programming becomes even more important. This is coming from memory (and I'm running on 4 kb), but I recall Intel even saying on their pages that it is difficult to optimize for this platform. There are even more rules, special cases, and so forth.
It's a pretty unusual architecture and I don't think any compilers would be able to output really tight code without a total back-end rewrite. A compiler, even optimized for IA-64, would have a harder time beating an Assembly programmer because of this. But once you get "into the groove" looks like it could be pretty nice.
Like I said, this is all coming from memory so I can't cite specific documents. But if anyone else would like to prove me otherwise (and I *hope* somebody does), please post a reply. I really look forward to working with 128 general purpose registers one day!
In all honestly, I think Intel should have scrapped IA-64 completely and adopted Alpha as its next platform. Backwards compatibility is killing them!
This is my perspective: I am not running a server to handle hundreds of "default.ida" GET requests. These requests are a violation of my bandwidth and processing time.
Admittedly the resources required to handle the requests are small, it does not change the principal. Assuming our laws are "ethical," one has to admit vandalism and trespassing do not always go unpunished.
But one thing really perplexes me. Code Red has been in the media spotlight for weeks (?) now and it still runs rampant. What will it take to get these people to get off of their fat asses and fix their servers?
Forgive my ignorance on this issue, but would it be possible to send back a bogus "default.ida" that will ruin their setup? What is this file anyway?
This is the best solution. The lazy-ass who is administering the server will be punished, it will draw attention to the problem, and may prevent further intrusions until the problem is fixed.
I hate to break it to you, but this thing isn't running Linux. It's running QNX RTP which is a helluvalot better than that slow bloated dung pile Linux. So please don't add insult to injury by calling it that!
Some quick notes I made from a few links and about 2 minutes of reading:
- The fact that Audrey is 'hackable' is probably 3Com's (Audrey's makers) fault and not QSSL's (QNX's makers) fault. 3Com designed and packaged the system.
- If they used BeIA, Windows CE (or whatever) using the same design, it would be equally as easy to 'hack.'
- Doing this hack requires an Audrey flash ROM image. Something that is not widely available. So, unless you have connections like this guy did, it's probably not very easy to do.