Might not be so good for those late night sessions;)
Seriously, though, what if you need to attend to something which is independant from the computer? Like if your toast is burning, and you need to whip your head around to see why it smells like your pantry exploded? What if you were lining up a shot with a sniping scope in Counterstrike just then? No good!
It is an interesting side effect indeed . . . however, the minute quantum forces become significant at this level so I think you reach a limit where "Adding one more atom" really is as difficult as 18 months of research and design, and then perhaps to the point where it is impossible.
Hey, I've got an idea! Let's use gluon fields with the gluons as the transistors in thequantum computer - that way, when we need another gluon, we just increase the field size! Just another interesting quantum effect tidbit you really wouldn't care to know: by increasing the distance between two gluons, you can make more between them - which is why the strong force increases in strength with distance, to a point.
Yet I digress.
-Leo
Sorry, it was written in C, but the function was defined by an array of bytes, hence machine code, not really C. Pure C, of course would have naturally run on both! But this was just using C to program in machine code.
Yes, it will "run", but it is being interpretted. Note that I said _run_/natively/, meaning on the CPU, not on a virtual machine of a different platform. It has been done! Look at one great hack from the IOCCC which ran, I believe, on a VAX and a Sparc (written in C) due to some interesting properties of the binary formats of both platforms. Find it on http://www.ioccc.org/
Hey, great, an all in one search tool!
Hey, I've got an idea for what to make next! Let's make the OS totally GUI and combine the shell with a web browser!;)
Just kidding, guys, it's great to see novel ideas in the *nix world. Even after more than two decades! Still working and getting better.
Yes, I was indeed being sarcastic. Secondly, I am mistaken about the dingo, I intended to refer to the Australian wolf (or is it Tazmanian? I'm not sure) which was hunted out of existance by sheep ranchers when Australia was relatively uninhabited.
Well, ed, this isn't really proof of evolution. God might haev created all of these species, but they died out due to human ignorance and we killed them a long time ago (the dingo dog? remember that?).
It's not really proof for or against evolution, but if evolution is accepted (which it widely is, of course, due to real evidence like inheritance from DNA etc.) then this can be used as evidence of our ancestry. But not really proof of evolution. A different science has that evidence.
The only proof against evolution which I can think of right now, though, is the platypus.
Although readability is neccessary in code, it is more imporant that it works. Certain concepts are hard to code, and some algorithms have to be implemented in a certain way so that they work how you want them to. Library functions, for instance, require speed. Although you could code them "beautifully", without a perfect optimizer (which really doesn't exist) it would be slower than coding the function for that purpose.
The most important niche for readability is in new code, high level code, or constantly changing code. Maybe some others. Those are the places that you need to be able to understand the algorithm by looking at the code and/or comments. If something is rock solid and is not going change, is well documented and tested, the code doens't have to be pretty since it works how expected and nobody needs terribly to read it. If you're working on a multiperson project, though, and your code is likely to change, it's a good idea to document it and code it prettily so others can tell if they're adding or subtracting.
And, as always, it is important to stress the engineers'/scientists'/programmers' motto: Function before Fasion.
I suppose that for the person who ported this, it was not about playing it on his PDA - more of being able to port a 3D engine to a pocket device, which I think is very cool, even if I'm not going to play it.
Although I have had a few good teachers, I have had many more terrible ones, and what motivated me was my despise of them. Maybe I should give some examples.
In 7th grade, I had an awesome Latin teacher: he used donut holes and jokes to teach us Latin. In 8th grade I unlearned most of what i learned since my teacher was mediocre. I was unmotivated that year, but in 9th grade I had the good teacher again and it was a great year. Then in 10th grade, I had a despicable teacher who didn't know Latin himself, let alone posses any ability to teach it. However, I conquered that year because I hated him so much. I got a 99 on the final when he expected a 75 or so of me.
More examples might be necessary: my 8th grade science teacher constantly forgot which way the earth rotated, and other pertinent principles. However, I hated her with such a holy passion that I aced the course and learned more than an only mediocre teacher would have taught me since i was forced to learn from outside sources.
So good teachers might be a good thing, but terrible ones can work well too.
Hopefully, in the future, self-centerd religions won't proclaim their date system as the unversal standard, and, perhaps Timothy (who I of course respect and mean no offense to) will not use the term "third millenium," which, even if measured in earth years is wildly inaccurate. Or at least he will give a valid reference point, as in "the third millenium past the presumed birth year of the figure unquestioningly worshipped by a large portion of society."
Maybe there is a slight chance that there will be less ethnocentrism in the future.
Happy New Year, New Century, and New Millenium (past the presumed birth year of the figure unquestioningly worshipped by a large portion of society)!
I know power is watts or Amp Volts or anything equivalent, but you get the meaning I was getting at, right? I know it doesn't make sense, and it's probably a mangled character, but it does make a tad more sense than an angstrom-hour, right? that's like a meter second, which isn't used all that much in classical mechanics if I'm not mistaken . . . but it's still funny
Yes, that is the symbol for an angstrom, however, I believe that they meant one Ampere-hour, which means it will run at one amp for one hour for that amount of fuel. It's the rate of fuel usage and the power derived from that amount of fuel.
well actually the pressure within such a massive gas ball ensure that there will be a solid at the core. I dunno about diamond as Clarke thinks, but metallic Hydrogen always sounded pretty reasonable. In fact, I remember seeing an article or two about it. However, where it goes from gas to solid (any liguid in between? I doubt it) might not be so well defined. the pressure would dramatically increase as you approached the center, then it would become extremely dense and it would be very difficult to move through it, and below the point where you have almost no mobility I'm sure you would say is solid. But right on the surface there it's pretty thich too!
After a little bit of digging around, I found that VIA is planning to introduce a Socket A chipset which includes SMP support (but only two-way). This chipset will be called the Apollo Pro KX266, and their roadmap has a little schpeil about it. That takes care of the processor (AMD) the chipset (VIA) and I really hope that somebody makes a motherboard to work with this chipset. Also, VIA says that the motherboards which will be based on this should support FireWire - sweet! I'm betting on Asus, Biostar, or Abit to come out with a mobo for the KX266, they currently make mobos for VIA's KX133. I expect to see this!
As I've said before, OOPS! I don't use perl, I just randomly see it being used around me. I'm a C/C++ person, so don't bug me with your little interpreted string parsers. feh!;)
That's what symlinks and shell aliases are for. And bash's default config file aliases ls to dir for all you DOS people, so you don't have to think too hard;)
That's an excellent idea! ok, but now it's time to rewrite anything that depends on certain things being in certain places. number one: the linux kernel expects init to be in one of several places which include/bin/init,/sbin/init and the like - but if it's not there it will panic (but only if it can't find a shell to dump you into first, which is likely if/bin is not/bin). However, if you just want to change directory names, use symlinks - you don't need a config file for that.
It is infinitely configurable. But Linux, along with the other unices, is made to be a server - and servers are made to be used by users, not administrators (they have their own user accounts). The users are definitely used to the common directory structure. Sure, you can do whatever you want your own box, but your users might not know what the fsck is going on.
there is a REASON for it to go into/usr/local/bin/quake2. There is a reason for (almost) everything in *nix based systems, including the organization of directory structures. this was all "planned out" - well evolved actually. the point is that most people are USED to the directory structures where configuration files are in/etc, home directories are in/home, and so on. people EXPECT perl to be in/usr/sbin/perl, not something like/mystuff/perl. So whereas Installshield lets you pick where things go, on *nix boxen it is better to pu something in the most obvious place for it. which is why it doens't ask you where to put it. of course you can force these things to happen, but it's simpler if things are where they are expected. if my passwd file was in/configuration/passwords, people would be missing something . . . if you catch my drift. So let it be - the directory structure is accepted and proven!
It's perfectly feasible, and would work just like a normal *nix character device, in almost every way. The only problem is quite slow access. For one thing, it is originally compressed (gz'd) so if every read/write went through a process optimized for say memory usage then the file would have to be decompressed every time. If it is kept as data in memory then writes to the physical data on disk would not be synced with the memory. So there are more practicality problems than feasibility. This are all managable and hack-around-able, but like many things that failed do to their reliability upon well-written programs using the API, it is likely to not work if someone does not know what they are doing (but then again it is *nix so that's true more often than not). Cooperative threads are one of those things that trust that "threads" will play nice - but not always. The same way, this fs would have to rely on people playing nicely, eg making sure that the memory is synced with the disk and so on. Well ANYhoo someone can always do something - Where there's a will, there's a hack.
-The LionMan
Slashdot Mirror
Might not be so good for those late night sessions ;)
Seriously, though, what if you need to attend to something which is independant from the computer? Like if your toast is burning, and you need to whip your head around to see why it smells like your pantry exploded? What if you were lining up a shot with a sniping scope in Counterstrike just then? No good!
It is an interesting side effect indeed . . . however, the minute quantum forces become significant at this level so I think you reach a limit where "Adding one more atom" really is as difficult as 18 months of research and design, and then perhaps to the point where it is impossible.
Hey, I've got an idea! Let's use gluon fields with the gluons as the transistors in thequantum computer - that way, when we need another gluon, we just increase the field size! Just another interesting quantum effect tidbit you really wouldn't care to know: by increasing the distance between two gluons, you can make more between them - which is why the strong force increases in strength with distance, to a point.
Yet I digress.
-Leo
Sorry, it was written in C, but the function was defined by an array of bytes, hence machine code, not really C. Pure C, of course would have naturally run on both! But this was just using C to program in machine code.
Yes, it will "run", but it is being interpretted. Note that I said _run_ /natively/, meaning on the CPU, not on a virtual machine of a different platform. It has been done! Look at one great hack from the IOCCC which ran, I believe, on a VAX and a Sparc (written in C) due to some interesting properties of the binary formats of both platforms. Find it on http://www.ioccc.org/
Hey, great, an all in one search tool!
Hey, I've got an idea for what to make next! Let's make the OS totally GUI and combine the shell with a web browser!;)
Just kidding, guys, it's great to see novel ideas in the *nix world. Even after more than two decades! Still working and getting better.
Yes, I was indeed being sarcastic. Secondly, I am mistaken about the dingo, I intended to refer to the Australian wolf (or is it Tazmanian? I'm not sure) which was hunted out of existance by sheep ranchers when Australia was relatively uninhabited.
Well, ed, this isn't really proof of evolution. God might haev created all of these species, but they died out due to human ignorance and we killed them a long time ago (the dingo dog? remember that?).
It's not really proof for or against evolution, but if evolution is accepted (which it widely is, of course, due to real evidence like inheritance from DNA etc.) then this can be used as evidence of our ancestry. But not really proof of evolution. A different science has that evidence.
The only proof against evolution which I can think of right now, though, is the platypus.
I bet a lot of Mickeysoft employees believe some of this stuff . . . FUD within the company!
Although readability is neccessary in code, it is more imporant that it works. Certain concepts are hard to code, and some algorithms have to be implemented in a certain way so that they work how you want them to. Library functions, for instance, require speed. Although you could code them "beautifully", without a perfect optimizer (which really doesn't exist) it would be slower than coding the function for that purpose.
The most important niche for readability is in new code, high level code, or constantly changing code. Maybe some others. Those are the places that you need to be able to understand the algorithm by looking at the code and/or comments. If something is rock solid and is not going change, is well documented and tested, the code doens't have to be pretty since it works how expected and nobody needs terribly to read it. If you're working on a multiperson project, though, and your code is likely to change, it's a good idea to document it and code it prettily so others can tell if they're adding or subtracting.
And, as always, it is important to stress the engineers'/scientists'/programmers' motto: Function before Fasion.
I suppose that for the person who ported this, it was not about playing it on his PDA - more of being able to port a 3D engine to a pocket device, which I think is very cool, even if I'm not going to play it.
Although I have had a few good teachers, I have had many more terrible ones, and what motivated me was my despise of them. Maybe I should give some examples.
In 7th grade, I had an awesome Latin teacher: he used donut holes and jokes to teach us Latin. In 8th grade I unlearned most of what i learned since my teacher was mediocre. I was unmotivated that year, but in 9th grade I had the good teacher again and it was a great year. Then in 10th grade, I had a despicable teacher who didn't know Latin himself, let alone posses any ability to teach it. However, I conquered that year because I hated him so much. I got a 99 on the final when he expected a 75 or so of me.
More examples might be necessary: my 8th grade science teacher constantly forgot which way the earth rotated, and other pertinent principles. However, I hated her with such a holy passion that I aced the course and learned more than an only mediocre teacher would have taught me since i was forced to learn from outside sources.
So good teachers might be a good thing, but terrible ones can work well too.
Hopefully, in the future, self-centerd religions won't proclaim their date system as the unversal standard, and, perhaps Timothy (who I of course respect and mean no offense to) will not use the term "third millenium," which, even if measured in earth years is wildly inaccurate. Or at least he will give a valid reference point, as in "the third millenium past the presumed birth year of the figure unquestioningly worshipped by a large portion of society."
Maybe there is a slight chance that there will be less ethnocentrism in the future.
Happy New Year, New Century, and New Millenium (past the presumed birth year of the figure unquestioningly worshipped by a large portion of society)!
I know power is watts or Amp Volts or anything equivalent, but you get the meaning I was getting at, right? I know it doesn't make sense, and it's probably a mangled character, but it does make a tad more sense than an angstrom-hour, right? that's like a meter second, which isn't used all that much in classical mechanics if I'm not mistaken . . . but it's still funny
Yes, that is the symbol for an angstrom, however, I believe that they meant one Ampere-hour, which means it will run at one amp for one hour for that amount of fuel. It's the rate of fuel usage and the power derived from that amount of fuel.
well actually the pressure within such a massive gas ball ensure that there will be a solid at the core. I dunno about diamond as Clarke thinks, but metallic Hydrogen always sounded pretty reasonable. In fact, I remember seeing an article or two about it. However, where it goes from gas to solid (any liguid in between? I doubt it) might not be so well defined. the pressure would dramatically increase as you approached the center, then it would become extremely dense and it would be very difficult to move through it, and below the point where you have almost no mobility I'm sure you would say is solid. But right on the surface there it's pretty thich too!
After a little bit of digging around, I found that VIA is planning to introduce a Socket A chipset which includes SMP support (but only two-way). This chipset will be called the Apollo Pro KX266, and their roadmap has a little schpeil about it. That takes care of the processor (AMD) the chipset (VIA) and I really hope that somebody makes a motherboard to work with this chipset. Also, VIA says that the motherboards which will be based on this should support FireWire - sweet! I'm betting on Asus, Biostar, or Abit to come out with a mobo for the KX266, they currently make mobos for VIA's KX133. I expect to see this!
You arrogant, ignorant fool - this has nothing to do with linux's security, which is on the same level as any other UNIX - MD5, baby!
As I've said before, OOPS! I don't use perl, I just randomly see it being used around me. I'm a C/C++ person, so don't bug me with your little interpreted string parsers. feh! ;)
That's what symlinks and shell aliases are for. And bash's default config file aliases ls to dir for all you DOS people, so you don't have to think too hard ;)
That's an excellent idea! ok, but now it's time to rewrite anything that depends on certain things being in certain places. number one: the linux kernel expects init to be in one of several places which include /bin/init, /sbin/init and the like - but if it's not there it will panic (but only if it can't find a shell to dump you into first, which is likely if /bin is not /bin). However, if you just want to change directory names, use symlinks - you don't need a config file for that.
Sorry, I don't really use perl. My bad . . .
It is infinitely configurable. But Linux, along with the other unices, is made to be a server - and servers are made to be used by users, not administrators (they have their own user accounts). The users are definitely used to the common directory structure. Sure, you can do whatever you want your own box, but your users might not know what the fsck is going on.
there is a REASON for it to go into /usr/local/bin/quake2. There is a reason for (almost) everything in *nix based systems, including the organization of directory structures. this was all "planned out" - well evolved actually. the point is that most people are USED to the directory structures where configuration files are in /etc, home directories are in /home, and so on. people EXPECT perl to be in /usr/sbin/perl, not something like /mystuff/perl. So whereas Installshield lets you pick where things go, on *nix boxen it is better to pu something in the most obvious place for it. which is why it doens't ask you where to put it. of course you can force these things to happen, but it's simpler if things are where they are expected. if my passwd file was in /configuration/passwords, people would be missing something . . . if you catch my drift. So let it be - the directory structure is accepted and proven!
Which happens to be the most stable and respected implementation of an operating system to date - still around because it work how it's supposed to!
It's perfectly feasible, and would work just like a normal *nix character device, in almost every way. The only problem is quite slow access. For one thing, it is originally compressed (gz'd) so if every read/write went through a process optimized for say memory usage then the file would have to be decompressed every time. If it is kept as data in memory then writes to the physical data on disk would not be synced with the memory. So there are more practicality problems than feasibility. This are all managable and hack-around-able, but like many things that failed do to their reliability upon well-written programs using the API, it is likely to not work if someone does not know what they are doing (but then again it is *nix so that's true more often than not). Cooperative threads are one of those things that trust that "threads" will play nice - but not always. The same way, this fs would have to rely on people playing nicely, eg making sure that the memory is synced with the disk and so on. Well ANYhoo someone can always do something - Where there's a will, there's a hack.
-The LionMan