For the past few years, you've had to be a registered business/company in Australia to get.net.au or.com.au, and a non-profit organistation registered within Australia to get.org.au.
I wouldn't say the DNS regulation is completely shot to hell - after all, good luck getting.edu.
Court Martial that sentenced Pvt. Slovak to death for dissertion during WW-II. All of those officers believed that a higher court would commute the sentence, and meanwhile they could avoid appearing "weak."
From a purely legal perspective; if it is illegal to publish and sell a book about manufacturing illegal drugs, perhaps it should also be illegal to publish it anywhere.
How does this work, since in principle it seems to be in violation of the first amendment?
Or maybe, if it's all commercial, you go to your games store, buy a NES emulator and a cartridge reader that plugs into the USB port or whatever it is the X-Box has, and play genuine, real NES carts?
The very first program I wrote was for a dBASE III Plus clone called dBXL... I was 8 at the time. I'd say the sheer simplicity of the language was a big plus.
Imagine my astonishment when I graduated to Clipper and discovered you could *gasp* define your own functions!
Re:Put it in the hands of a known agentcy
on
Pirate DNS?
·
· Score: 1
Sorry. The trolls have been getting to me - I've lost my sense of humour by the third beer post. (At least the penis birds were only a few lines long).
Re:Put it in the hands of a known agentcy
on
Pirate DNS?
·
· Score: 2
Pffffttt. The format of a URL is protocol://hostname/path-on-host. The protocol:// portion of the URL has nothing to do with the DNS. Neither does the path-on-host for that matter.
For this reason I fail to find the above funny at all.
Re:Systemised defects.. not on same rack
on
Linux And Beijing
·
· Score: 1
I quote: Whoopsie. I come from China.
The point Iwas making is that given you (a) come from China and (b) clearly believe life in Chine is superior to life in the US, why aren't you in China?
I may have been mistaken in assuming you're not still in China (I just looked at altavista.net), but then, why are you using a webmail account?
There is a different between the Chinese people and the Chinese government. We're discriminating against an institution, not a race. The Chinese government could be run by a bunch of white people and I'd feel exactly the same way about them. Trolling for Tianamen!
Re:Systemised defects.. not on same rack
on
Linux And Beijing
·
· Score: 1
If China is so great, then why do you have an American email address?
There's the small problem of physics. It's a lot easier to get fast speeds at the micron level than the centimetre level. For a long the bus was stuck at 66mhz while designers struggled with RF interference between the tracks on the motherboard.
Cache size is a tradeoff for cost VS performance one one level. On the other hand, having too large a cache can decrease performance in tight loops etc. Remember that memory seek time is c + (1-h)m, where c is cache access time, h the hit ratio and m memory access time. If you've got software that's already optimised for high hit ratios on smaller caches (as most modern software is) increasing the cache size from 2 MB to 4 MB will likely increase cache access time a lot more than the not as dramatically increased hit ratio can counter for, so your mean access time actually increases.
psDoom symbolises processes as monsters in a modified version of Doom - you kill a process by killing the associated monster.
psDoom is based upon Dennis Chao's Doom Sysadmin Tool project, which also jots has some further thoughts on the application of this concept to actual process management in an environment with multiple users and administrators. This actually made the front page of Slashdot last year.
Actually, I suspect there'd be quite a few BSc's at Red Hat. And as a CS student, I've taken a look at the prospects and I'm aiming for high marks... then there might be a slight chance I can get into some interesting R&D rather than reimplementing the wheel.
... aren't working right now, I'm going to suggest that the systems administrators from the School of Computing at Curtin University go along and learn how to install Redhat properly.
Curtin Uni is literally across the road from Canning College (location of the Perth installfest), so I'm sure that for the lack of trouble it would put them through the student body would benefit.
A) There is no Virtual Machine, there is a virtual processor which is different as in there is no loss of speed
A virtual processor is a virtual machine.
B) The SDK runs on top of linux, simply to assist porting apps from it and others. The OS runs nativly on 14+ CPUs and even if you code in Assembler its still portable.
I wasn't aware of the 14+ CPUs, didn't seem to mention it in the main article - I stand corrected. Still, if you're coding in "assembler" and it runs on 14+ different CPUs, there's a virtual machine/virtual processor/emulator doing a lot of work.
C) The Amiga apps are easily faster than ones on linux and they around 50% the size of normal linux apps and they consume far less memory
How can something running on a virtual processor on Linux be faster than a native Linux app? Maybe the application and/or the underlying SDK possess some more efficient algorithms, but were those same algorithms implemented on top of the Linux native APIs it would be just as fast if not faster.
As for the 'size' of native apps... well, that's the machine code, and you'd be referring to the size of the code compiled to Amiga instructions as opposed to (probably) x86 instructions. That's an Intel/IA-32 thing, not a Linux thing, and completely unrelated to the OS. CISC code, which is favourable for emulation/virtual machines, is known to be generally a lot smaller than RISC code (and a lot of optimised Pentium and later code stick to the basic IA-32 instructions, RISC-style, as the code runs a lot faster).
As far as I can see it's just Yet Another Proprietary Programming Environment. What does this really bring to the average coder?
For all this "surprisingly fast" alpha blending, I fail to see how a VM running on top of Linux can provide faster alpha blending than an app built directly on top of Linux (implementing the same algorithms) could.
Besides, what with the entire Java mess, do we really need yet another virtual environment?
I wouldn't say the DNS regulation is completely shot to hell - after all, good luck getting .edu.
I'm interested. Got a link?
How does this work, since in principle it seems to be in violation of the first amendment?
Or maybe, if it's all commercial, you go to your games store, buy a NES emulator and a cartridge reader that plugs into the USB port or whatever it is the X-Box has, and play genuine, real NES carts?
Hasn't it already been established that emulators like Bleem are legal?
Uhuh. If all the Chinese liked their Government, I doubt the Government would feel the need to run them over with tanks.
Imagine my astonishment when I graduated to Clipper and discovered you could *gasp* define your own functions!
Sorry. The trolls have been getting to me - I've lost my sense of humour by the third beer post. (At least the penis birds were only a few lines long).
For this reason I fail to find the above funny at all.
The point Iwas making is that given you (a) come from China and (b) clearly believe life in Chine is superior to life in the US, why aren't you in China?
I may have been mistaken in assuming you're not still in China (I just looked at altavista.net), but then, why are you using a webmail account?
There is a different between the Chinese people and the Chinese government. We're discriminating against an institution, not a race. The Chinese government could be run by a bunch of white people and I'd feel exactly the same way about them. Trolling for Tianamen!
If China is so great, then why do you have an American email address?
The next time my little brother asks how the entire Internet fits inside that little box, I'll just tell him Alexa put it there.
No, use wxWindows.
You left out AmigaOS.
Cache size is a tradeoff for cost VS performance one one level. On the other hand, having too large a cache can decrease performance in tight loops etc. Remember that memory seek time is c + (1-h)m, where c is cache access time, h the hit ratio and m memory access time. If you've got software that's already optimised for high hit ratios on smaller caches (as most modern software is) increasing the cache size from 2 MB to 4 MB will likely increase cache access time a lot more than the not as dramatically increased hit ratio can counter for, so your mean access time actually increases.
It would be okay if they didn't go making life difficult for overclockers as well.
To the contrary.. I'm an undergraduate CompSci student, and the best stuff we do doesn't take us near a keyboard.
psDoom is based upon Dennis Chao's Doom Sysadmin Tool project, which also jots has some further thoughts on the application of this concept to actual process management in an environment with multiple users and administrators. This actually made the front page of Slashdot last year.
Actually, I suspect there'd be quite a few BSc's at Red Hat. And as a CS student, I've taken a look at the prospects and I'm aiming for high marks ... then there might be a slight chance I can get into some interesting R&D rather than reimplementing the wheel.
Uhuh. So long as the engineering and CAD/CAM crowds buy as much stuff as they do, the hardcore graphics support is going to stay in there.
Curtin Uni is literally across the road from Canning College (location of the Perth installfest), so I'm sure that for the lack of trouble it would put them through the student body would benefit.
Whatever happened to Oog the Caveman? I miss him :(
A virtual processor is a virtual machine.
B) The SDK runs on top of linux, simply to assist porting apps from it and others. The OS runs nativly on 14+ CPUs and even if you code in Assembler its still portable.
I wasn't aware of the 14+ CPUs, didn't seem to mention it in the main article - I stand corrected. Still, if you're coding in "assembler" and it runs on 14+ different CPUs, there's a virtual machine/virtual processor/emulator doing a lot of work.
C) The Amiga apps are easily faster than ones on linux and they around 50% the size of normal linux apps and they consume far less memory
How can something running on a virtual processor on Linux be faster than a native Linux app? Maybe the application and/or the underlying SDK possess some more efficient algorithms, but were those same algorithms implemented on top of the Linux native APIs it would be just as fast if not faster.
As for the 'size' of native apps... well, that's the machine code, and you'd be referring to the size of the code compiled to Amiga instructions as opposed to (probably) x86 instructions. That's an Intel/IA-32 thing, not a Linux thing, and completely unrelated to the OS. CISC code, which is favourable for emulation/virtual machines, is known to be generally a lot smaller than RISC code (and a lot of optimised Pentium and later code stick to the basic IA-32 instructions, RISC-style, as the code runs a lot faster).
For all this "surprisingly fast" alpha blending, I fail to see how a VM running on top of Linux can provide faster alpha blending than an app built directly on top of Linux (implementing the same algorithms) could.
Besides, what with the entire Java mess, do we really need yet another virtual environment?