I remember using Mac 'Live CDs' back in the System 7 days, and they were passe back then. Funny how Linux is only just catching up to the technology Apple had a decade ago.
Ever since the first networks, the "holy grail" of networking computing has been to provide a programming interface in which you can access remote resources the same way as you access local resources. The network becomes "transparent".
One example of network transparency is the famous RPC (remote procedure call), a system designed so that you can call procedures (subroutines) running on another computer on the network exactly as if they were running on the local computer. An awful lot of energy went into this. Another example, built on top of RPC, is Microsoft's Distributed COM (DCOM), in which you can access objects running on another computer as if they were on the current computer.
Sounds logical, right?
Wrong.
There are three very major differences between accessing resources on another machine and accessing resources on the local machine:
Availability,
Latency, and
Reliability.
When you access another machine, there's a good chance that machine will not be available, or the network won't be available. And the speed of the network means that it's likely that the request will take a while: you might be running over a modem at 28.8kbps. Or the other machine might crash, or the network connection might go away while you are talking to the other machine (when the cat trips over the phone cord).
Any reliable software that uses the network absolutely must take this into account. Using programming interfaces that hide all this stuff from you is a great way to make a lousy software program.
A quick example: suppose I've got some software that needs to copy a file from one computer to another. On the Windows platform, the old "transparent" way to do this is to call the usual CopyFile method, using UNC names for the files such as \\SERVER\SHARE\Filename.
If all is well with the network, this works nicely. But if the file is a megabyte long, and the network is being accessed over a modem, all kinds of things go wrong. The entire application freezes while a megabyte file is transferred. There is no way to make a progress indicator, because when CopyFile was invented, it was assumed that it would always be "fast". There is no way to resume the transfer if the phone connection is lost.
Realistically, if you want to transfer a file over a network, it's better to use an API like FtpOpenFile and its related functions. No, it's not the same as copying a file locally, and it's harder to use, but this function was built with the knowledge that network programming is different than local programming, and it provides hooks to make a progress indicator, to fail gracefully if the network is unavailable or becomes unavailable, and to operate asynchronously.
Conclusion: the next time someone tries to sell you a programming product that lets you access network resources the same was as you access local resources, run full speed in the opposite direction.
Much of Linux' popularity is due to its status as the rebel OS, not the lenient licensing. Solaris, on the other hand, has a far more conservative public image -- it's just not considered cool amongst most Linux fans.
It also doesn't help that Solaris' file I/O is so fucking slow.
Hopefully we'll see this happen here in the United States, too. Given the intelligence (or lack thereof) of the current administration, however, it does not look likely.
Slashdot Mirror
Misery fucks you in the ass over and over.
Will be missed, etc.
I remember using Mac 'Live CDs' back in the System 7 days, and they were passe back then. Funny how Linux is only just catching up to the technology Apple had a decade ago.
The OP specified a fast toolkit. GTK+ sucks, Xfce uses GTK+, therefore Xfce sucks. Then again, Xfce sucks plenty on its own.
Seriously, why don't you take a look at the dozens of posts identical to yours that show up in every single fucking story in the BSD section.
src code plz
Oh fuck, S.M. covering the Verlaines' Death & The Maiden. The best 9/11 ever.
OH GOD JOEL, TOUCH ME.
X.org has lame little dropshadows everywhere. From the same guy that fucked up Xft.
Yes, I have.
Nice poem, faggot.
MOD PARENT DOWN MORONS.
Ever since the first networks, the "holy grail" of networking computing has been to provide a programming interface in which you can access remote resources the same way as you access local resources. The network becomes "transparent".
One example of network transparency is the famous RPC (remote procedure call), a system designed so that you can call procedures (subroutines) running on another computer on the network exactly as if they were running on the local computer. An awful lot of energy went into this. Another example, built on top of RPC, is Microsoft's Distributed COM (DCOM), in which you can access objects running on another computer as if they were on the current computer.
Sounds logical, right?
Wrong.
There are three very major differences between accessing resources on another machine and accessing resources on the local machine:
When you access another machine, there's a good chance that machine will not be available, or the network won't be available. And the speed of the network means that it's likely that the request will take a while: you might be running over a modem at 28.8kbps. Or the other machine might crash, or the network connection might go away while you are talking to the other machine (when the cat trips over the phone cord).
Any reliable software that uses the network absolutely must take this into account. Using programming interfaces that hide all this stuff from you is a great way to make a lousy software program.
A quick example: suppose I've got some software that needs to copy a file from one computer to another. On the Windows platform, the old "transparent" way to do this is to call the usual CopyFile method, using UNC names for the files such as \\SERVER\SHARE\Filename.
If all is well with the network, this works nicely. But if the file is a megabyte long, and the network is being accessed over a modem, all kinds of things go wrong. The entire application freezes while a megabyte file is transferred. There is no way to make a progress indicator, because when CopyFile was invented, it was assumed that it would always be "fast". There is no way to resume the transfer if the phone connection is lost.
Realistically, if you want to transfer a file over a network, it's better to use an API like FtpOpenFile and its related functions. No, it's not the same as copying a file locally, and it's harder to use, but this function was built with the knowledge that network programming is different than local programming, and it provides hooks to make a progress indicator, to fail gracefully if the network is unavailable or becomes unavailable, and to operate asynchronously.
Conclusion: the next time someone tries to sell you a programming product that lets you access network resources the same was as you access local resources, run full speed in the opposite direction.
Nothing new. It's done better in functional languages like OCaml which ensure type safety without even having to explicitly declare types.
That's VIM, not vi.
Much of Linux' popularity is due to its status as the rebel OS, not the lenient licensing. Solaris, on the other hand, has a far more conservative public image -- it's just not considered cool amongst most Linux fans.
It also doesn't help that Solaris' file I/O is so fucking slow.
Hopefully we'll see this happen here in the United States, too. Given the intelligence (or lack thereof) of the current administration, however, it does not look likely.