And not just battery life in hours, but also battery life in months. I have seen so many devices with rechargeable batteries that die after 10-15 months it's beginning to look like an epidemic.
It's all data-dependent. While compression can get huge gains on plain text traffic such as smtp email, or ftp of uncompressed files, it will get close to nothing on encrypted or already compressed data (ssh, vpn's (ipsec, etc), ssh, http (with modern browsers). On data like that, there is no repetitive data and losless algorithms can not reduce the number of bits, except something on the headers, and packets like the tcp-ack, resulting in only a small speed increase due to compression.
But still I wish the ietf would select a standard for between-router compression, and then my cable provider support it;-) every software speedup is good, even if it's only 4% an not even close to 400%.
On that subject: Note that for speeding on www, using a proxy-cache, such as squid can often achieve a 10%-40% bandwidth saving at a cost of less than 500MB disk space per user, and doesn't need special hardware on both ends of the link (just on the user/office end). From a user standpoint the proxy-cache gives a much larger speed increase, due to the pages loading faster because the latency of getting an object from the cache in the proxy is so much faster than from the other web site (no, the 'cache' in your web browser doesn't even perform close to what squid can do, especially if you have multiple people/pc's behind the proxy). At home behind a fast cable modem, I even notice a web browsing speed increase with the proxy-cache.
"To run one of these you just find it and run it. One step (that typically requires root access) is skipped - installation.
That is basically it from the end user viewpoint. It is more secure because for these end-user type apps no root access is required."
"apt-cache search" to find it, and "apt-get install" to install it is not any harder than how to find & install it with 0install.
From the enduser viewpoint it is no more secure, because that new unzip program you found with google and installed with 0install will still go to you mozilla and office directory, add a keylogger and spyware to them, then goes on and forwards all incoming emails, and sends the documents, and tax returns to an anonymous hotmail address, emails everybody in your contact list with a copy of itself, and start a daemon that listens on an unprivileged port for incoming connections from Mr Hacker. And it is very happy that it doesn't need root access for all that, just like it is on most windows machines right now.
Exactly, and that is what I have problems with. Even starting a single program that then downloads its updated from the internet takes longer than just downloading and installing the update, for example, openoffice may not load/run the spelling check library/module until I click 'spell check', so it won't update the it until I try to use it.
But additionally I have hundreds of programs that get updated when I do a dist-upgrade. I don't have time to start them all (for example because I have a flight to catch), and I have no way of predicting which programs I will actually need later when I'm in the no-internet zone...
In what you suggested, if there are differences between the 'local' library and the global library, then sometimes the program will run with version 1 and sometimes it will run with version 2.
Those differences can exist, even if the libraries were compiled from the same version of their source code, because the local libraries are compiled by whoever makes the 'bundle', and that person may have used a different version of the compiler, or may have used diffferent versions of include files for APIs to other libraries, or may have compiled it with different compiler flags. That way the two libraries will both say that they are 'version 1.2.3.4', but they will not be exactly the same. Even if the differences are only small such as differences in run-time of certain functions, that still may trigger race conditions with one of the two libraries and never having problems with the other.
Besides that, how do you deal with library codependency issues? Suppose liba and libb where liba_v1.3 is shipped with proga, and liba_v1.3 requires libb_v1.2.5, so libb_v1.2.5 is shipped with proga. But then libb_v1.2.5 has a known bug for your printer, and for libb_v1.2.6 the bug is fixed. Then you won't be able to use proga with your printer, even though proga may work perfectly fine with liba_v1.3.1 and libb_v1.2.6 and therefore with no bugs for your printer.
It for when it gets more complicated, that is why we have installers and packages with dependency lists.
So you're saying that 0install will not replace apt-get, because you would still need apt-get to install things like apache?
Then how do you install, for example, a program that comes with a client and server? First apt-get the server and then 0install the client?
Note that programs like apache and sshd need root priviliges for example to bind to the port, and they change to a non-root UID right after the point when they don't need root privileges anymore (apache after binding to the port, sshd after the chuid when somebody has authenticated). So again, security is added by 0install. When a user runs a program they also run as that user, with the restricted permissions that come with that.
I call 0install making things unnecessarily complicated.
"Yes, if you install programs in your own directories and run them then any app you run can delete or replace those programs. This has nothing to do with ROX or 0install. ROX and 0install are no different from any other linux/unix system in this regard."
I made the comment that from a system security standpoint, 0install adds nothing, and you seem to basically agree with that. I made the comment because of a statement of the parent poster: If 0install doesn't add anything to security, then why did tal197 say "Reducing the security risk from traditional installation systems (APT, RPM, etc where you're running a downloaded install script as root) was an important goal for Zero Install."
"But if you didn't have Internet access the first time you ran it, how would you run it at all?"
Because I had internet access when I installed it. That is the big difference. My debian installation has many hundreds of programs. I just do an 'apt-get dist-upgrade' at home or in the office, and that updates everything to the very latest versions. I have time to type 'apt-get dist-upgrade' and then continue with other things to prepare for my trip. When the dist-upgrade is finished, I can trust on my harddisk containing all programs, so that when I start this program wehn I'm in the airplane, or run that script that needs this other program or library, that I won't be stuck with a message that I need to connect to the Internet to continue... And for the desktops, I can rest assured that all programs that I chose to install on my desktop will work even if I lose the connection to the Internet.
"For 'normal' installation you need Internet access or a CD first. Same here."
Nope, because zero-install defers the downloading to when you run the program first, and apt-get does it when it is convenient for me to wait for a download from the Internet.
"Also consider this, for the average person not only is this a more secure form of distribution, its more efficient, its easier, and for 99% of files people will download it just works. "
Back to the question at the start of this thread: this is already done with apt-get.
So what if you're not on-line when you run an application for the first time? For example, on laptops that may happen a lot.
The reason why we install a program is so that it is there to work for us when we need it, not just when we need it for the second and following times.
People already complain about download times of programs, if the first startup of a program includes the download, then the first experience with the program will be 'took forever just to start up'...
Your idea will result in applications that suddenly work differently/stop working, depending on which other applications were started first. Cure worse than the disease. Totally nuts.
"I think future versions of Windows know how to scan the disk periodically,"
Ah, another built-in system slowdown-to-halt because-our-package-management-system-sucks.
AAAAAH!. Time to frag, uh, defrag. No, registry cleanup! No, emptry trash can! No, virusscan!, No scan for & remove spyware!, No weekly/monthly security-patch post-install reboot!
Still it's nothing new that dpkg and apt-get already do, except for needing Internet access when you run a program for the first time, and many other things like not getting unexpected behaviour if you uninstall by deleting the directory while the program is still running, and ending up with a gazillion directories of a gazillion different versions of libraries but knowing nothing about which programs depend on it.
If all code runs as you, and is installed so that you as a user can delete/create/copy/overwrite programs, then from a system security standpoint you've achieved nothing. For example: what stops a rogue program from deleting mozilla and installing a trojaned program with the same name in its place?
So how do you zero install, for example, apache? Or anything else that needs to bind a port 1024 or has another good reason for root permissions to run.
Well, reading that description, I don't see anything useful that can already be given by a simple gui on top of 'apt-get install' and 'apt-get remove', except a bunch of missing important features such as: that the zeroinstall-ed program won't work if you don't have Internet connectivity when you run the program for the first time (think laptops for example).
Sure, you could add that feature to zeroinstall, but then you're actually installing things, so maybe with that feature it should be called 'oneinstall'? And you may save a lot of time by just using the already existing package manager programs to do all that.
"Symlinks into contained application directories mean that uninstallation and upgrading can be done without worrying about leaving parts around your system. "
Except for the dangling symlinks?
Uninstallation without worrying about leaving parts around your system is 'dpkg --purge' (or 'dpkg -r' is you don't want to delete the settings/configuration). For upgrading, that would be 'dpkg -i' or 'apt-get install'.
"If you want multiple versions, one of them is going to be the one that gets called by the app's name, you can't avoid that. I'd probably make a system where it selects the latest one."
No need to dream about that, or plan to make it. The debian package manager (dpkg), uses symlinks and "/etc/defaults" to do that. Don't force select the 'latest one', because that doesn't always make sense: for example "www-browser", which is a runnable program on debian, you can set it up to choose any www-browser capable program: mozilla, firefox, opera, konqueror, etc. Now, which one of those would you call the 'latest one'? It's a choice and it has been implemented a long time ago in Debian.
"If you have a script to symlink everything after any installation, the problem goes away."
That already exists. It is what we call a 'packager'. On debian it's 'dpkg', and on redhat/fedora it's 'rpm' and it contains scripts for pre-installation, post-installation, pre-removal, and post-removal that handle everything from clean shutdown of program (parts) that may still be running, to symlink creation and undangling.
This 'zero install' really is somebody with a NIH syndrome (not-invented-here so let's start something new from scratch, and by the time we looked at all the details we end up with something very close to what already existed, but we have more bugs that still need ironing-out). Actually it's a "nothing new to see here, move on"...
By the way. I have invented this device. It is a round object that makes it a lot easier to move non-round objects around. I'm calling it a 'wheel'. I think it is so much better than those inneficient airplanes we use now.
"Sorry folks, we have the technology right now to support multiple version of libraries at the same time"
Yes, for many years now and it is working very well, and no it doesn't need this 'everything in one directory' setup.
"disk space is no longer an issue,"
Libraries are not made to save disk space, they are made to allow reuse of code, and often made available in an OS as dynamically linked libraries (*.so.*, *.DLL) to save RAM, not disk space.
"Applications locking in to configuration files across the file-system has to go."
And debian administrators totally agree with that, and that is why/etc is used for all configuration files.
Administration is made easy with your packager. There is no need to force all files in one directory: "dpkg --listfiles" will show you all files that a package has and using apt-get to install and remove packages takes care of all things related to copying/deleting files, package/library dependencies and downloading...
It shouldn't even be hard to make an app ('file browser gui') that makes a standard debian machine look like it has each program in its own directory for those who think they can do administation better with that UI.
Hopefully, this takes off in more of the 'newbie oriented' distros so that we can say "Just type cp/software/openoffice/usr/software to install" instead of./configure && make && make install.:)
I still would like to know how they plan on fixing library dependencies, but... assuming they get over that, I'll be very happy once this is released.
Ouch!
What is up with these people? Don't they know about "apt-get install openoffice.org"? It does everything needed, it does the copy and takes care of the dependencies. It even adds it to the menus and filetypes.
Somehow I dont get how "cp/software/openoffice/usr/software" plus worry about dependencies is a step forward from "apt-get install openoffice.org".
There are just so many things wrong with using "cp" to install, I don't know where to begin. Actually I do know where to begin: just how does a 'install with cp' OS find a library or binary to load/execute (does it search all of/usr/software/*/bin/*?). Good luck, your application should be loaded by next week or so.
And how about filetypes, if you doubleclick on a file, then does the filemanager go to all programs in/usr/software/* and run a program there as in to check "Do you support this file type"? Double click -> time to get coffee...
An application just needs to register with other OS components when it becomes available on an OS, and it needs to deregister when you remove it. That is why we have packagers (deb(dpkg)/rpm, or on windows installers/uninstallers).
"You'd think Bill had a vested interest in all this.."
Of course,
I think he is fully enveloped in his haze cloud of 'dotnet', where he sees a couple (one?) of companies making dotnet components by writing source code, and all other companies just dragging and dropping them around to make 'dotnet apps'.
Microsoft has discovered that for other programmers, a lot of the value in their OS are the libraries and SDKs that they supply with it. 'Ow golly, they made a compression/buttonbar/fileopen/codec/network/whate ver dll, now we don't have to make our own'. And they have extended that model to the 'future' with dotnet, by transposing the dll's they make inhouse to dotnet components that are web/network/internet/collaboration/drm-enabled etc.
At their 'dotnet' rollout, expect a giant deluge of dotnet components of the magnitude such that a lot of people will say 'hey, now I don't need to make my own/fill-in-the-blank/ anymore'. The 'applications' those people make will require that end-users have the Microsoft 'dotnet' library, which will be outrageously expensive like windows is now. Drumroll, they have created themselves a new software monopoly that will take over when their OS+Office monopoly falls apart.
That's how I see it and I think its pretty accurate.
"how the fuck can you manage huge programs with visual representations?"
Obviously, powperjoint;-)
Now seriously, I think he is in his haze cloud of 'dotnet', where he sees a couple (one?) of companies making dotnet components by writing source code, and all other companies just dragging and dropping them around to make 'dotnet apps'.
Microsoft has discovered that for other programmers, a lot of the value in their OS are the libraries and SDKs that they supply with it. 'Ow golly, they made a compression/buttonbar/fileopen/codec/network/whate ver dll, now we don't have to make our own'. And they have extended that model to the 'future' with dotnet, by transposing the dll's they make inhouse to dotnet components that are web/network/internet/collaboration/drm-enabled etc.
At their 'dotnet' rollout, expect a giant deluge of dotnet components of the magnitude such that a lot of people will say 'hey, now I don't need to make my own/fill-in-the-blank/ anymore'. The 'applications' those people make will require that end-users have the Microsoft 'dotnet' library, which will be outrageously expensive like windows is now. Drumroll, they have created themselves a new software monopoly that will take over when their OS+Office monopoly falls apart.
That's how I see it and I think its pretty accurate.
What's on the paper may very well have value, but is the only thing that can be (and in some occasions is) totally free.
Note that the metaphorical equivalents of Microsofts flagship products (OS, Office) put down on the paper are the pen, the letterhead, layout, and font, not the actual text that would be of most value. They are the tools so that somebody can sit down and write the bestselling book, not the book itself.
Now, because of open source, you will not be paying $0.05 for your paper (PC) plus an extra $1 for the pen and letterhead (OS/Office), plus it will give you more choice of pens and letterheads and a chance to even modify them.
Slashdot Mirror
And not just battery life in hours, but also battery life in months. I have seen so many devices with rechargeable batteries that die after 10-15 months it's beginning to look like an epidemic.
It's all data-dependent. While compression can get huge gains on plain text traffic such as smtp email, or ftp of uncompressed files, it will get close to nothing on encrypted or already compressed data (ssh, vpn's (ipsec, etc), ssh, http (with modern browsers). On data like that, there is no repetitive data and losless algorithms can not reduce the number of bits, except something on the headers, and packets like the tcp-ack, resulting in only a small speed increase due to compression.
;-) every software speedup is good, even if it's only 4% an not even close to 400%.
But still I wish the ietf would select a standard for between-router compression, and then my cable provider support it
On that subject: Note that for speeding on www, using a proxy-cache, such as squid can often achieve a 10%-40% bandwidth saving at a cost of less than 500MB disk space per user, and doesn't need special hardware on both ends of the link (just on the user/office end). From a user standpoint the proxy-cache gives a much larger speed increase, due to the pages loading faster because the latency of getting an object from the cache in the proxy is so much faster than from the other web site (no, the 'cache' in your web browser doesn't even perform close to what squid can do, especially if you have multiple people/pc's behind the proxy). At home behind a fast cable modem, I even notice a web browsing speed increase with the proxy-cache.
"To run one of these you just find it and run it. One step (that typically requires root access) is skipped - installation.
That is basically it from the end user viewpoint. It is more secure because for these end-user type apps no root access is required."
"apt-cache search" to find it, and "apt-get install" to install it is not any harder than how to find & install it with 0install.
From the enduser viewpoint it is no more secure, because that new unzip program you found with google and installed with 0install will still go to you mozilla and office directory, add a keylogger and spyware to them, then goes on and forwards all incoming emails, and sends the documents, and tax returns to an anonymous hotmail address, emails everybody in your contact list with a copy of itself, and start a daemon that listens on an unprivileged port for incoming connections from Mr Hacker. And it is very happy that it doesn't need root access for all that, just like it is on most windows machines right now.
It's a step backwards, that's what it is.
Exactly, and that is what I have problems with. Even starting a single program that then downloads its updated from the internet takes longer than just downloading and installing the update, for example, openoffice may not load/run the spelling check library/module until I click 'spell check', so it won't update the it until I try to use it.
But additionally I have hundreds of programs that get updated when I do a dist-upgrade. I don't have time to start them all (for example because I have a flight to catch), and I have no way of predicting which programs I will actually need later when I'm in the no-internet zone...
In what you suggested, if there are differences between the 'local' library and the global library, then sometimes the program will run with version 1 and sometimes it will run with version 2.
Those differences can exist, even if the libraries were compiled from the same version of their source code, because the local libraries are compiled by whoever makes the 'bundle', and that person may have used a different version of the compiler, or may have used diffferent versions of include files for APIs to other libraries, or may have compiled it with different compiler flags. That way the two libraries will both say that they are 'version 1.2.3.4', but they will not be exactly the same. Even if the differences are only small such as differences in run-time of certain functions, that still may trigger race conditions with one of the two libraries and never having problems with the other.
Besides that, how do you deal with library codependency issues? Suppose liba and libb where liba_v1.3 is shipped with proga, and liba_v1.3 requires libb_v1.2.5, so libb_v1.2.5 is shipped with proga. But then libb_v1.2.5 has a known bug for your printer, and for libb_v1.2.6 the bug is fixed. Then you won't be able to use proga with your printer, even though proga may work perfectly fine with liba_v1.3.1 and libb_v1.2.6 and therefore with no bugs for your printer.
It for when it gets more complicated, that is why we have installers and packages with dependency lists.
So you're saying that 0install will not replace apt-get, because you would still need apt-get to install things like apache?
Then how do you install, for example, a program that comes with a client and server? First apt-get the server and then 0install the client?
Note that programs like apache and sshd need root priviliges for example to bind to the port, and they change to a non-root UID right after the point when they don't need root privileges anymore (apache after binding to the port, sshd after the chuid when somebody has authenticated). So again, security is added by 0install. When a user runs a program they also run as that user, with the restricted permissions that come with that.
I call 0install making things unnecessarily complicated.
"Yes, if you install programs in your own directories and run them then any app you run can delete or replace those programs. This has nothing to do with ROX or 0install. ROX and 0install are no different from any other linux/unix system in this regard."
I made the comment that from a system security standpoint, 0install adds nothing, and you seem to basically agree with that. I made the comment because of a statement of the parent poster: If 0install doesn't add anything to security, then why did tal197 say "Reducing the security risk from traditional installation systems (APT, RPM, etc where you're running a downloaded install script as root) was an important goal for Zero Install."
"But if you didn't have Internet access the first time you ran it, how would you run it at all?"
Because I had internet access when I installed it. That is the big difference. My debian installation has many hundreds of programs. I just do an 'apt-get dist-upgrade' at home or in the office, and that updates everything to the very latest versions. I have time to type 'apt-get dist-upgrade' and then continue with other things to prepare for my trip. When the dist-upgrade is finished, I can trust on my harddisk containing all programs, so that when I start this program wehn I'm in the airplane, or run that script that needs this other program or library, that I won't be stuck with a message that I need to connect to the Internet to continue... And for the desktops, I can rest assured that all programs that I chose to install on my desktop will work even if I lose the connection to the Internet.
"For 'normal' installation you need Internet access or a CD first. Same here."
Nope, because zero-install defers the downloading to when you run the program first, and apt-get does it when it is convenient for me to wait for a download from the Internet.
"Also consider this, for the average person not only is this a more secure form of distribution, its more efficient, its easier, and for 99% of files people will download it just works. "
Back to the question at the start of this thread: this is already done with apt-get.
So what if you're not on-line when you run an application for the first time? For example, on laptops that may happen a lot.
The reason why we install a program is so that it is there to work for us when we need it, not just when we need it for the second and following times.
People already complain about download times of programs, if the first startup of a program includes the download, then the first experience with the program will be 'took forever just to start up'...
Your idea will result in applications that suddenly work differently/stop working, depending on which other applications were started first. Cure worse than the disease. Totally nuts.
"I think future versions of Windows know how to scan the disk periodically,"
Ah, another built-in system slowdown-to-halt because-our-package-management-system-sucks.
AAAAAH!. Time to frag, uh, defrag. No, registry cleanup! No, emptry trash can! No, virusscan!, No scan for & remove spyware!, No weekly/monthly security-patch post-install reboot!
Talk about ease of administration...
Still it's nothing new that dpkg and apt-get already do, except for needing Internet access when you run a program for the first time, and many other things like not getting unexpected behaviour if you uninstall by deleting the directory while the program is still running, and ending up with a gazillion directories of a gazillion different versions of libraries but knowing nothing about which programs depend on it.
"System security? Nothing. All code runs as you."
If all code runs as you, and is installed so that you as a user can delete/create/copy/overwrite programs, then from a system security standpoint you've achieved nothing. For example: what stops a rogue program from deleting mozilla and installing a trojaned program with the same name in its place?
So how do you zero install, for example, apache? Or anything else that needs to bind a port 1024 or has another good reason for root permissions to run.
Well, reading that description, I don't see anything useful that can already be given by a simple gui on top of 'apt-get install' and 'apt-get remove', except a bunch of missing important features such as: that the zeroinstall-ed program won't work if you don't have Internet connectivity when you run the program for the first time (think laptops for example).
Sure, you could add that feature to zeroinstall, but then you're actually installing things, so maybe with that feature it should be called 'oneinstall'? And you may save a lot of time by just using the already existing package manager programs to do all that.
"Symlinks into contained application directories mean that uninstallation and upgrading can be done without worrying about leaving parts around your system. "
Except for the dangling symlinks?
Uninstallation without worrying about leaving parts around your system is 'dpkg --purge' (or 'dpkg -r' is you don't want to delete the settings/configuration). For upgrading, that would be 'dpkg -i' or 'apt-get install'.
"If you want multiple versions, one of them is going to be the one that gets called by the app's name, you can't avoid that. I'd probably make a system where it selects the latest one."
No need to dream about that, or plan to make it. The debian package manager (dpkg), uses symlinks and "/etc/defaults" to do that. Don't force select the 'latest one', because that doesn't always make sense: for example "www-browser", which is a runnable program on debian, you can set it up to choose any www-browser capable program: mozilla, firefox, opera, konqueror, etc. Now, which one of those would you call the 'latest one'? It's a choice and it has been implemented a long time ago in Debian.
"If you have a script to symlink everything after any installation, the problem goes away."
That already exists. It is what we call a 'packager'. On debian it's 'dpkg', and on redhat/fedora it's 'rpm' and it contains scripts for pre-installation, post-installation, pre-removal, and post-removal that handle everything from clean shutdown of program (parts) that may still be running, to symlink creation and undangling.
This 'zero install' really is somebody with a NIH syndrome (not-invented-here so let's start something new from scratch, and by the time we looked at all the details we end up with something very close to what already existed, but we have more bugs that still need ironing-out). Actually it's a "nothing new to see here, move on"...
Yeah, good point. It's a been-there-done-that.
By the way. I have invented this device. It is a round object that makes it a lot easier to move non-round objects around. I'm calling it a 'wheel'. I think it is so much better than those inneficient airplanes we use now.
"Sorry folks, we have the technology right now to support multiple version of libraries at the same time"
/etc is used for all configuration files.
Yes, for many years now and it is working very well, and no it doesn't need this 'everything in one directory' setup.
"disk space is no longer an issue,"
Libraries are not made to save disk space, they are made to allow reuse of code, and often made available in an OS as dynamically linked libraries (*.so.*, *.DLL) to save RAM, not disk space.
"Applications locking in to configuration files across the file-system has to go."
And debian administrators totally agree with that, and that is why
Administration is made easy with your packager. There is no need to force all files in one directory: "dpkg --listfiles" will show you all files that a package has and using apt-get to install and remove packages takes care of all things related to copying/deleting files, package/library dependencies and downloading...
It shouldn't even be hard to make an app ('file browser gui') that makes a standard debian machine look like it has each program in its own directory for those who think they can do administation better with that UI.
Hopefully, this takes off in more of the 'newbie oriented' distros so that we can say "Just type cp /software/openoffice /usr/software to install" instead of ./configure && make && make install. :)
... assuming they get over that, I'll be very happy once this is released.
/software/openoffice /usr/software" plus worry about dependencies is a step forward from "apt-get install openoffice.org".
/usr/software/*/bin/*?). Good luck, your application should be loaded by next week or so.
/usr/software/* and run a program there as in to check "Do you support this file type"? Double click -> time to get coffee...
I still would like to know how they plan on fixing library dependencies, but
Ouch!
What is up with these people? Don't they know about "apt-get install openoffice.org"? It does everything needed, it does the copy and takes care of the dependencies. It even adds it to the menus and filetypes.
Somehow I dont get how "cp
There are just so many things wrong with using "cp" to install, I don't know where to begin. Actually I do know where to begin: just how does a 'install with cp' OS find a library or binary to load/execute (does it search all of
And how about filetypes, if you doubleclick on a file, then does the filemanager go to all programs in
An application just needs to register with other OS components when it becomes available on an OS, and it needs to deregister when you remove it. That is why we have packagers (deb(dpkg)/rpm, or on windows installers/uninstallers).
"and $400 for a copy of Microsoft Office"
Huh? $0 for a copy of office software with more features than what you'll need for SOHO or home use.
Hihi
Do you realize that you just wrote that function again, ON SLASHDOT?
Oh, but D) it does guarantee the consulting company a new project before 2012...
Actually, regular expressions are the power of Perl. I know of a lot of people who use it mainly because of the power of the language.
Hmm. That library 'already exists' huh? So where are the apps? I guess the plan failed.
"You'd think Bill had a vested interest in all this.."
e ver dll, now we don't have to make our own'. And they have extended that model to the 'future' with dotnet, by transposing the dll's they make inhouse to dotnet components that are web/network/internet/collaboration/drm-enabled etc.
/fill-in-the-blank/ anymore'. The 'applications' those people make will require that end-users have the Microsoft 'dotnet' library, which will be outrageously expensive like windows is now. Drumroll, they have created themselves a new software monopoly that will take over when their OS+Office monopoly falls apart.
Of course,
I think he is fully enveloped in his haze cloud of 'dotnet', where he sees a couple (one?) of companies making dotnet components by writing source code, and all other companies just dragging and dropping them around to make 'dotnet apps'.
Microsoft has discovered that for other programmers, a lot of the value in their OS are the libraries and SDKs that they supply with it. 'Ow golly, they made a compression/buttonbar/fileopen/codec/network/what
At their 'dotnet' rollout, expect a giant deluge of dotnet components of the magnitude such that a lot of people will say 'hey, now I don't need to make my own
That's how I see it and I think its pretty accurate.
"how the fuck can you manage huge programs with visual representations?"
;-)
e ver dll, now we don't have to make our own'. And they have extended that model to the 'future' with dotnet, by transposing the dll's they make inhouse to dotnet components that are web/network/internet/collaboration/drm-enabled etc.
/fill-in-the-blank/ anymore'. The 'applications' those people make will require that end-users have the Microsoft 'dotnet' library, which will be outrageously expensive like windows is now. Drumroll, they have created themselves a new software monopoly that will take over when their OS+Office monopoly falls apart.
Obviously, powperjoint
Now seriously, I think he is in his haze cloud of 'dotnet', where he sees a couple (one?) of companies making dotnet components by writing source code, and all other companies just dragging and dropping them around to make 'dotnet apps'.
Microsoft has discovered that for other programmers, a lot of the value in their OS are the libraries and SDKs that they supply with it. 'Ow golly, they made a compression/buttonbar/fileopen/codec/network/what
At their 'dotnet' rollout, expect a giant deluge of dotnet components of the magnitude such that a lot of people will say 'hey, now I don't need to make my own
That's how I see it and I think its pretty accurate.
What's on the paper may very well have value, but is the only thing that can be (and in some occasions is) totally free.
Note that the metaphorical equivalents of Microsofts flagship products (OS, Office) put down on the paper are the pen, the letterhead, layout, and font, not the actual text that would be of most value. They are the tools so that somebody can sit down and write the bestselling book, not the book itself.
Now, because of open source, you will not be paying $0.05 for your paper (PC) plus an extra $1 for the pen and letterhead (OS/Office), plus it will give you more choice of pens and letterheads and a chance to even modify them.