We are way offtopic at this point, but, since you mentioned it... AMD's Fab 30 (their new.18 micron facility) is in Dresden, Germany. I'm sure Siemens (for example) makes microprocessors, although whether they manufacture them *in* Europe is another story.
That is a nice argument for local control of tariffs, although I think it speaks more strongly for global environmental protection treaties... but anyway, what does pollution have to do with writing and selling software?
You don't implement tax law by monitoring each individual sale... I've never seen a government official checking up on transactions in the supermarket, for example. (Perhaps they do, but I would expect they do spot checks anonymously, so that is looking for opportunities to take violators to court, and not a normal procedure.)
You just put a law on the books (or on the WTO "book", in which case members must enforce it as local law because of the terms of whatever treaty they signed on to) that says you have to report certain types of commerce and collect taxes on them, and then turn those over to the government. If it is the responsibility of an incorporated business to pay the taxes, they usually will. If you make it the consumers job, as in the case of sales tax on interstate sales in the US, then you dont get quite as much of it....
If, in your example, the buyer and seller are both British, it doesn't seem like there is much ambiguity about what is going on from a financial standpoint.
What I'm curious about is what governing authority gets the tax money from tariffs like this. If it is the national government of the seller, then what difference does it make to less developed nations anyway? (Assuming they aren't doing relatively more selling, which could be totally wrong, considering that writing software requires a lot less capital than many "high-tech" economic activities.)
Actually, GUI code is something that deserves optimization... consider how annoying a slow GUI can be, for example doing 'make menuconfig' on an older PC. GUI responsiveness is a major factor in user perception of the speed of a computer, and a lot of GUIs I've had to use wouldn't have been hurt by a bit of performance tuning. That said, other things still come first, of course....
Technically speaking, Linux also offers enterprises a migration path to support 64-bit applications as soon as they become available.... Microsoft, Novell and other OS vendors are still at least a year away from providing 64-bit application support at the OS level....
Is Linux really so 64-bit clean? I know that the VFS layer is not on 32-bit architectures, and I haven't yet heard that glibc2 and kernel 2.2 are totally cleaned up even on e.g. Alpha and UltraSPARC. Someone who has had more recent experience please let me know... last time it mattered I found myself using cruft like llseek(), *shudder*.
I am sure of one thing: Linux is not ahead of Solaris on 64-bit cleanliness of interfaces. I have yet to come across any documented interface in Solaris 2.6 that is neither 64-bit nor has an explicit 64-bit equivalent.
"Novell will use open-source publishing when it makes sense," says Brian Faustin, Novell's director of product marketing for NetWare. "It doesn't make sense for the network operating system because we need to maintain our value-add through security and reliability features. Our customers don't want us to give away source code."
First, I've never heard of any licensee of any software that would be *unhappy* if they got source with it, quite the contrary... and I don't believe "open source" implies "give away source".
Second, I don't see how customers having source could decrease reliability (except versus attacks, which is really a security issue). And availability of source has a record of improving security and reliability via peer-review; what Netware exploits I have seen did not appear to involve more than interface knowledge, and in some cases would likely have had one-line fixes.
But I'm sure everyone that agrees with me has heard all this before.
Re:HOW did you get the voodoo 3 to run q3test!?
on
John Carmack on Linux
·
· Score: 1
silly question... are you running the x server with -bpp 16?
i think there is a howto. visit this index and look around; there is one for 3dfx hardware and one for quake, among others.
Hmm, "linux" and "com"mercial... I hope they host things like the Linux Business Solutions Project. I realize it looks like PHB fodder, but I've found that page useful in the past myself.
Hmm. Reading... They sound just a little too paranoid to me. The reason so much European traffic is going through Vienna VIRGINIA is not the NSA, or even BGP finding empty routes through the US, exactly... it's because European long distance rates are so high it's cheaper to cross the Atlantic twice!
I agree about mailing this to elected officials. (Non-US readers too?) There may be a lot of corrupt and dishonest politicians, but some of them really are working for you, and they can't do much about this sort of activity within the government if they don't know about it or don't have any evidence. (I don't think the day to day activities of the NSA are a common topic of discussion in Congress; perhaps they should be.)
Picking up a gun is not the way to make your country better. Don't assume you have no power as a citizen beyond the threat of force; that should be your *last* resort. Realize that the you have much more potential influence over government in the US than the average person in most other countries does over theirs. Speak to your representatives about this, because someone should.
I hope this gets some coverage in the mainstream press, and some real inquiry from our own government.
Try my post below about the report link. Be warned, it looks like a scanned fax.
It would be plenty responsible for me to vote; I administer a CAD lab at a university. Most of the students in here are mechanical engineering undergraduates. There is a ProE class in here twice a week. And most of the machines in the room are PCs that dual boot Linux and NT.
The most vexing Linux problem we ran into was with the Linux kernel itself. There are countless revisions of the kernel available, and in tests we found that some Linux patches worked only with certain kernels or with specific versions of applications. This inconsistency could wreak havoc on departments trying to optimize a Linux server to run multiple applications.
Like nothing ever breaks after you apply a service pack to NT. In my experience, the changes between kernel versions are limited and reasonably well documented, and you only get bitten by them if you are too lazy to read. Usually you don't notice at all; if any userspace interfaces changed, probably libc did too.
The numbers get even more interesting when comparing the results of NetWare with and without Opp Locks. When we turned on Opp Locks, NetWare's overall performance improved by about 40 percent.
However, this gain is deceiving. With Opp Locks enabled, almost every operation in NetWare actually slows by 25 percent. The exception is file write operations, which are faster by 300 percent. Because writing files takes up almost 40 percent of the NetBench test, it's no wonder we saw a huge overall performance boost in our results.
These people haven't a clue what they are benchmarking. Opportunistic locks allow the client to do whatever it likes to a file (or regions thereof) without synchronizing with the server. Of course write speed increases; the network isn't involved anymore! You haven't increased server performance one whit, but rather prevented more than one client from opening the file for writing at the same time.
There is nothing special about "engineers" that makes them better than "hackers". Those labels are not even exclusive; the best hacker I know has an engineering degree. You do not know what a hacker is, if you think they are necessarily unaware of computer science and engineering principles; and in my experience, the more eager a person is to call themself a "software engineer", the less competent they are.
As for Cutler, his work on VMS doesn't give me great confidence in him. VMS is stable and useful to some, but it's far from being my favorite OS. He may be awfully serious about it; he may be awfully serious about NT, too, but that doesn't mean I want to spend any time using it, or that it meets my needs.
Linus has a proven track record of writing solid code and coordinating a massive development effort. He does not just say that microkernels are stupid--he demonstrates by example that the monolithic approach is still viable. As elegant as I think microkernel architectures are, Linux is still what runs on my servers.
Ah, but the PC Week test was just static documents! Redhat 6.0 comes with an RPM for Squid, but instead of installing that, they use Apache and then gripe about how expensive it is to fork for each request.
It's unclear to me what use there is for a web server that is eating bandwidth about the way ftp.cdrom.com does, anyway. That doesn't strike me as a typical "enterprise application". That part of the benchmark is obviously contrived.
If I understand some of the discussion here, then a superconductor stops having zero resistance as soon as you draw enough current through it, because you generate a magnetic field that screws up the superconducting properties (i.e., it gets a nonzero resistance). This seems at odds to me with some of the things they use superconductors for, like very strong magnets. Are they just using a very thick "wire" of material, to keep the internal field strength low?
This makes superconductors seem more useful for computing (low current/voltage) and less useful for things like power transistors, which was my first thought for an application when reading the blurb.
If I understand some of the other discussion here, then all they found was that if they doped a known superconductor with some other material, then they could adjust the critical temperature a few degrees by applying a current. That is a much less general result, and it makes more sense to me. Not sure what applications behavior like that has... a thermometer that works on a very narrow range, operated by bisection (numerical methods sense)?
Someone who understands the physics better, please enlighten me.
No reason to be that scared. Backup anything important; if you are lazy and have lots of space, just backup the whole raw partition to somewhere else on the network. Then no matter how badly the kernel mangles your disk, it is very easy to return it to a known good state. The NTFS module is quite unstable; even read-only it has locked up solid (repeatably, so I should work on finding the bug, *sigh*). But I've never lost any data to it, and only a little time.
I realize that its not practical if you are low on disk space and don't have the luxury of a Sun server full of big disks nearby, but I often find myself using gzip and an rsh pipe to send an entire partition or disk over the network to a file server before attempting something questionable. (Heck, I occasionally reinstall Windows boxen that way:)
Also, it might be good to look into the history of the HPFS r/w code... if it is known to be relatively stable, and has just been waiting to be mainlined because of the feature freeze preceding 2.2, then I wouldn't be too nervous about using it. (I don't know in this case; not an OS/2 fan, personally.)
Unless your file is very large, writing is easier than reading, because buffering can cover the seeking latency. The dirty blocks sit in main memory for a while, then when the bus has a chance they sit in the controller cache, then in the disk's cache, and then when the head is in the right spot they finally get committed to media.
Also, with a heavily used disk running a good filesystem, large writes are more likely to be contiguous on disk than reads.
When I'm testing TCP networking performance, I give the web server a file that is just a hole (length huge, size just a few indirect blocks) and use a command line http client. Works nicely: # httpget -v http://.../~ambrose/hole -o/dev/null 67108864/67108864 bytes transferred in 8.26 seconds (7930.47 kB/sec).
Slashdot Mirror
We are way offtopic at this point, but, since you mentioned it... AMD's Fab 30 (their new .18 micron facility) is in Dresden, Germany. I'm sure Siemens (for example) makes microprocessors, although whether they manufacture them *in* Europe is another story.
That is a nice argument for local control of tariffs, although I think it speaks more strongly for global environmental protection treaties... but anyway, what does pollution have to do with writing and selling software?
You don't implement tax law by monitoring each individual sale... I've never seen a government official checking up on transactions in the supermarket, for example. (Perhaps they do, but I would expect they do spot checks anonymously, so that is looking for opportunities to take violators to court, and not a normal procedure.)
You just put a law on the books (or on the WTO "book", in which case members must enforce it as local law because of the terms of whatever treaty they signed on to) that says you have to report certain types of commerce and collect taxes on them, and then turn those over to the government. If it is the responsibility of an incorporated business to pay the taxes, they usually will. If you make it the consumers job, as in the case of sales tax on interstate sales in the US, then you dont get quite as much of it....
If, in your example, the buyer and seller are both British, it doesn't seem like there is much ambiguity about what is going on from a financial standpoint.
What I'm curious about is what governing authority gets the tax money from tariffs like this. If it is the national government of the seller, then what difference does it make to less developed nations anyway? (Assuming they aren't doing relatively more selling, which could be totally wrong, considering that writing software requires a lot less capital than many "high-tech" economic activities.)
Actually, GUI code is something that deserves optimization... consider how annoying a slow GUI can be, for example doing 'make menuconfig' on an older PC. GUI responsiveness is a major factor in user perception of the speed of a computer, and a lot of GUIs I've had to use wouldn't have been hurt by a bit of performance tuning. That said, other things still come first, of course....
Technically speaking, Linux also offers enterprises a migration path to support 64-bit applications as soon as they become available. ... Microsoft, Novell and other OS vendors are still at least a year away from providing 64-bit application support at the OS level....
Is Linux really so 64-bit clean? I know that the VFS layer is not on 32-bit architectures, and I haven't yet heard that glibc2 and kernel 2.2 are totally cleaned up even on e.g. Alpha and UltraSPARC. Someone who has had more recent experience please let me know... last time it mattered I found myself using cruft like llseek(), *shudder*.
I am sure of one thing: Linux is not ahead of Solaris on 64-bit cleanliness of interfaces. I have yet to come across any documented interface in Solaris 2.6 that is neither 64-bit nor has an explicit 64-bit equivalent.
"Novell will use open-source publishing when it makes sense," says Brian Faustin, Novell's director of product marketing for NetWare. "It doesn't make sense for the network operating system because we need to maintain our value-add through security and reliability features. Our customers don't want us to give away source code."
First, I've never heard of any licensee of any software that would be *unhappy* if they got source with it, quite the contrary... and I don't believe "open source" implies "give away source".
Second, I don't see how customers having source could decrease reliability (except versus attacks, which is really a security issue). And availability of source has a record of improving security and reliability via peer-review; what Netware exploits I have seen did not appear to involve more than interface knowledge, and in some cases would likely have had one-line fixes.
But I'm sure everyone that agrees with me has heard all this before.
silly question... are you running the x server with -bpp 16?
i think there is a howto. visit this index and look around; there is one for 3dfx hardware and one for quake, among others.
Hmm, "linux" and "com"mercial... I hope they host things like the Linux Business Solutions Project. I realize it looks like PHB fodder, but I've found that page useful in the past myself.
Hmm. Reading... They sound just a little too paranoid to me. The reason so much European traffic is going through Vienna VIRGINIA is not the NSA, or even BGP finding empty routes through the US, exactly... it's because European long distance rates are so high it's cheaper to cross the Atlantic twice!
I agree about mailing this to elected officials. (Non-US readers too?) There may be a lot of corrupt and dishonest politicians, but some of them really are working for you, and they can't do much about this sort of activity within the government if they don't know about it or don't have any evidence. (I don't think the day to day activities of the NSA are a common topic of discussion in Congress; perhaps they should be.)
Picking up a gun is not the way to make your country better. Don't assume you have no power as a citizen beyond the threat of force; that should be your *last* resort. Realize that the you have much more potential influence over government in the US than the average person in most other countries does over theirs. Speak to your representatives about this, because someone should.
I hope this gets some coverage in the mainstream press, and some real inquiry from our own government.
Try my post below about the report link. Be warned, it looks like a scanned fax.
The one in the TechWeb article is slightly mangled... if you didn't figure it out, try this.
Check out the May 1999 STOA newsletter for a very quick summary (scroll down a bit). None of it is US authored, AFAICT.
It would be plenty responsible for me to vote; I administer a CAD lab at a university. Most of the students in here are mechanical engineering undergraduates. There is a ProE class in here twice a week. And most of the machines in the room are PCs that dual boot Linux and NT.
The most vexing Linux problem we ran into was with the Linux kernel itself. There are countless revisions of the kernel available, and in tests we found that some Linux patches worked only with certain kernels or with specific versions of applications. This inconsistency could wreak havoc on departments trying to optimize a Linux server to run multiple applications.
Like nothing ever breaks after you apply a service pack to NT. In my experience, the changes between kernel versions are limited and reasonably well documented, and you only get bitten by them if you are too lazy to read. Usually you don't notice at all; if any userspace interfaces changed, probably libc did too.
Isaac Newton, I think.
The numbers get even more interesting when comparing the results of NetWare with and without Opp Locks. When we turned on Opp Locks, NetWare's overall performance improved by about 40 percent.
However, this gain is deceiving. With Opp Locks enabled, almost every operation in NetWare actually slows by 25 percent. The exception is file write operations, which are faster by 300 percent. Because writing files takes up almost 40 percent of the NetBench test, it's no wonder we saw a huge overall performance boost in our results.
These people haven't a clue what they are benchmarking. Opportunistic locks allow the client to do whatever it likes to a file (or regions thereof) without synchronizing with the server. Of course write speed increases; the network isn't involved anymore! You haven't increased server performance one whit, but rather prevented more than one client from opening the file for writing at the same time.
There is nothing special about "engineers" that makes them better than "hackers". Those labels are not even exclusive; the best hacker I know has an engineering degree. You do not know what a hacker is, if you think they are necessarily unaware of computer science and engineering principles; and in my experience, the more eager a person is to call themself a "software engineer", the less competent they are.
As for Cutler, his work on VMS doesn't give me great confidence in him. VMS is stable and useful to some, but it's far from being my favorite OS. He may be awfully serious about it; he may be awfully serious about NT, too, but that doesn't mean I want to spend any time using it, or that it meets my needs.
Linus has a proven track record of writing solid code and coordinating a massive development effort. He does not just say that microkernels are stupid--he demonstrates by example that the monolithic approach is still viable. As elegant as I think microkernel architectures are, Linux is still what runs on my servers.
Ah, but the PC Week test was just static documents! Redhat 6.0 comes with an RPM for Squid, but instead of installing that, they use Apache and then gripe about how expensive it is to fork for each request.
It's unclear to me what use there is for a web server that is eating bandwidth about the way ftp.cdrom.com does, anyway. That doesn't strike me as a typical "enterprise application". That part of the benchmark is obviously contrived.
If I understand some of the discussion here, then a superconductor stops having zero resistance as soon as you draw enough current through it, because you generate a magnetic field that screws up the superconducting properties (i.e., it gets a nonzero resistance). This seems at odds to me with some of the things they use superconductors for, like very strong magnets. Are they just using a very thick "wire" of material, to keep the internal field strength low?
This makes superconductors seem more useful for computing (low current/voltage) and less useful for things like power transistors, which was my first thought for an application when reading the blurb.
If I understand some of the other discussion here, then all they found was that if they doped a known superconductor with some other material, then they could adjust the critical temperature a few degrees by applying a current. That is a much less general result, and it makes more sense to me. Not sure what applications behavior like that has... a thermometer that works on a very narrow range, operated by bisection (numerical methods sense)?
Someone who understands the physics better, please enlighten me.
No reason to be that scared. Backup anything important; if you are lazy and have lots of space, just backup the whole raw partition to somewhere else on the network. Then no matter how badly the kernel mangles your disk, it is very easy to return it to a known good state. The NTFS module is quite unstable; even read-only it has locked up solid (repeatably, so I should work on finding the bug, *sigh*). But I've never lost any data to it, and only a little time.
I realize that its not practical if you are low on disk space and don't have the luxury of a Sun server full of big disks nearby, but I often find myself using gzip and an rsh pipe to send an entire partition or disk over the network to a file server before attempting something questionable. (Heck, I occasionally reinstall Windows boxen that way :)
Also, it might be good to look into the history of the HPFS r/w code... if it is known to be relatively stable, and has just been waiting to be mainlined because of the feature freeze preceding 2.2, then I wouldn't be too nervous about using it. (I don't know in this case; not an OS/2 fan, personally.)
Unless your file is very large, writing is easier than reading, because buffering can cover the seeking latency. The dirty blocks sit in main memory for a while, then when the bus has a chance they sit in the controller cache, then in the disk's cache, and then when the head is in the right spot they finally get committed to media.
/dev/null
Also, with a heavily used disk running a good filesystem, large writes are more likely to be contiguous on disk than reads.
When I'm testing TCP networking performance, I give the web server a file that is just a hole (length huge, size just a few indirect blocks) and use a command line http client. Works nicely:
# httpget -v http://.../~ambrose/hole -o
67108864/67108864 bytes transferred in 8.26 seconds (7930.47 kB/sec).