I remapped the keyboard on my computer at work to Dvorak for a couple of months to try it out. At the end of that time I still wasn't up to my old QWERTY speed, but I did notice it involved a lot less finger movement. I can believe it would tend to be less prone to lead to repetitive stress problems.
Of course, RSI is caused more by the mouse than the keyboard, so I'm not sure this really matters anyway...
My main beefs with the registry are its binary format and its monolithic "single-file-does-everything" design. Fortunately it doesn't get corrupted often, but it does occasionally, and then I have to either take the time to repair it or revert to my app's default settings.
I don't deal with user vs. machine settings issue because I develop machine vision software for a manufacturing environment, and we only have one "user" for each NT system. Even if we did have different users, using.INI files works fine because each user would need the same settings, anyway.
A nice feature of using.INI files is that once I set up my options for the various products we manufacture, I can just grab the.INI files and copy them to another machine with my software. No need to reconfigure. Of course, I can export and import pieces of the registry, but it's much simpler to just copy a text file.
I also have options buried in my.INI files that aren't accessible from within my program (special modes for running tests, etc.), and it's easier and quicker to edit with a text editor than use RegEdit.
Finally, we archive our software and settings using a revision control system. Using.INI files makes it possible to isolate everything pertaining to a single application for this archiving.
OK, that works. I wasn't thinking of doing that way. I was thinking of going through the full steps to create a window, set up the message pump, yada yada yada. All the steps you would normally go through for a normal Windows app, but then just output "Hello, world." Doing it the long way would take many, many more lines.
I disagree. I have programmed with Win32, MFC, and GTK+, and am currently using MFC in my job. It DOES take 70+ lines of code to write a "Hello, world" program with Win32. That was one of the main reasons MFC was developed--to provide a more structured and simplified API.
Are you sure you aren't thinking of MFC? Using the Foundation Classes does make it possible to write a fairly compact program (compact source, anyway). These days it's common for many people to confuse MFC with straight Win32 programming, which isn't done very often anymore. I only use Win32 calls to read and write my software's.INI files (I hate the registry).
I haven't read the license in detail myself (just skimmed it), but Sun's new license may have some legal ramifications for other companies that agree to work under its terms. I know that my company's lawyers have recommended that NO ONE within my company accept the conditions of the license, lest it affect our ability to protect our own intellectual property.
Can anyone clarify this potential? Is this a valid concern, or just another case of corporate misunderstanding the spirit of open-source?
I noticed this as well. And it is also similar to the Christian concept of redemption in that Darth Vader's salvation did NOT undo or preclude the consequences. Millions of people died under the Emperor's tyranny, and Vader himself dies even as he is saved. Vader repents, but all is not turned right magically.
I agree that within the open-source model you can't make money from selling software if it is a product that would have a wide audience, e.g. word processors. But for a limited distribution product, like a high-end specialty CAD program, it would be unlikely that company X that paid $15K for it would be willing to share it with company Y for free. Of course, once someone did share it, the door would be wide open because the recipient company would feel free to share it with someone else, and so on. For applications like that true open-source may not be the way to go (gasp! Did I really say that?!)
In my opinion (which may or may not be on track), a shift to open source would require a major shift in thinking that doesn't view software as a way to make money directly, but as an enabler to sell hardware and support. Companies wouldn't write most software if they were interested in making money off of it; they would either write software to make their hardware product more attractive or make their hardware specs/APIs publicly available so other people would be able to write software for it. When products have a lot of freely available software for them, they tend to be popular. Look at the effect of the freeware/shareware software movements on the Apple II and other 8-bit computers, or the modern-day effect of open-source on Linux, and the *BSD Unices.
As for custom software (such as control software for manufacturing tooling), there are relatively few exceptional software designers/coders. Whether or not open-source is adopted, skilled programmers would still be in demand.
...and is the reason why my company puts clauses in our contracts that give us the rights to the source code for the software in our manufacturing equipment. It's not truly open-source, because we often will sign a non-disclosure agreement to satisfy the vendor's requirements, but we reserve the right to bring in outside consultants.
Of course, true open-source would be better for everyone in the long run, because companies that have equipment with similar functions or data handling requirements could leverage off of each other. I think it will take a while for that way of thinking to take hold in companies, though.
The goal of such software is not to make a profit on it, however (at least not directly). When people talk about "Open Source" or "Free Software" they are usually thinking about commercial applications. I agree with a previous poster that the way to make money in that arena is support. But even software released under the GPL can be sold for a price. The only restriction is the source code must be made available without additional cost. This usually has the effect of causing prices to be low (because the first customer who actually paid $$$ for it might share it for free, which is allowed under the GPL), but I can see a scenario where it doesn't for a limited distribution product (e.g. specialty CAD or simulation software).
1. To disable swap until you re-enable it, comment out any lines in your/etc/fstab that designate swap partitions (insert a '#' at the front of the line). Upon next reboot, swap will not be used (you can also turn it off with swapoff). Remove the '#' to re-enable (reboot or swapon required).
2. To disable swap until the next reboot, just use the swapoff command: swapoff -a To turn it back on, issue a swapon.
Slashdot Mirror
Does anyone else think the version shown on their opening page looks like Kenny from South Park?
I remapped the keyboard on my computer at work to Dvorak for a couple of months to try it out. At the end of that time I still wasn't up to my old QWERTY speed, but I did notice it involved a lot less finger movement. I can believe it would tend to be less prone to lead to repetitive stress problems.
Of course, RSI is caused more by the mouse than the keyboard, so I'm not sure this really matters anyway...
My main beefs with the registry are its binary format and its monolithic "single-file-does-everything" design. Fortunately it doesn't get corrupted often, but it does occasionally, and then I have to either take the time to repair it or revert to my app's default settings.
.INI files works fine because each user would need the same settings, anyway.
.INI files is that once I set up my options for the various products we manufacture, I can just grab the .INI files and copy them to another machine with my software. No need to reconfigure. Of course, I can export and import pieces of the registry, but it's much simpler to just copy a text file.
.INI files that aren't accessible from within my program (special modes for running tests, etc.), and it's easier and quicker to edit with a text editor than use RegEdit.
.INI files makes it possible to isolate everything pertaining to a single application for this archiving.
I don't deal with user vs. machine settings issue because I develop machine vision software for a manufacturing environment, and we only have one "user" for each NT system. Even if we did have different users, using
A nice feature of using
I also have options buried in my
Finally, we archive our software and settings using a revision control system. Using
OK, that works. I wasn't thinking of doing that way. I was thinking of going through the full steps to create a window, set up the message pump, yada yada yada. All the steps you would normally go through for a normal Windows app, but then just output "Hello, world." Doing it the long way would take many, many more lines.
I disagree. I have programmed with Win32, MFC, and GTK+, and am currently using MFC in my job. It DOES take 70+ lines of code to write a "Hello, world" program with Win32. That was one of the main reasons MFC was developed--to provide a more structured and simplified API.
.INI files (I hate the registry).
Are you sure you aren't thinking of MFC? Using the Foundation Classes does make it possible to write a fairly compact program (compact source, anyway). These days it's common for many people to confuse MFC with straight Win32 programming, which isn't done very often anymore. I only use Win32 calls to read and write my software's
Me, too. I installed it just a couple of weeks ago. Maybe it wasn't available for the other Un*ces. I guess I never checked.
I haven't read the license in detail myself (just skimmed it), but Sun's new license may have some legal ramifications for other companies that agree to work under its terms. I know that my company's lawyers have recommended that NO ONE within my company accept the conditions of the license, lest it affect our ability to protect our own intellectual property.
Can anyone clarify this potential? Is this a valid concern, or just another case of corporate misunderstanding the spirit of open-source?
I noticed this as well. And it is also similar to the Christian concept of redemption in that Darth Vader's salvation did NOT undo or preclude the consequences. Millions of people died under the Emperor's tyranny, and Vader himself dies even as he is saved. Vader repents, but all is not turned right magically.
I agree that within the open-source model you can't make money from selling software if it is a product that would have a wide audience, e.g. word processors. But for a limited distribution product, like a high-end specialty CAD program, it would be unlikely that company X that paid $15K for it would be willing to share it with company Y for free. Of course, once someone did share it, the door would be wide open because the recipient company would feel free to share it with someone else, and so on. For applications like that true open-source may not be the way to go (gasp! Did I really say that?!)
In my opinion (which may or may not be on track), a shift to open source would require a major shift in thinking that doesn't view software as a way to make money directly, but as an enabler to sell hardware and support. Companies wouldn't write most software if they were interested in making money off of it; they would either write software to make their hardware product more attractive or make their hardware specs/APIs publicly available so other people would be able to write software for it. When products have a lot of freely available software for them, they tend to be popular. Look at the effect of the freeware/shareware software movements on the Apple II and other 8-bit computers, or the modern-day effect of open-source on Linux, and the *BSD Unices.
As for custom software (such as control software for manufacturing tooling), there are relatively few exceptional software designers/coders. Whether or not open-source is adopted, skilled programmers would still be in demand.
...and is the reason why my company puts clauses in our contracts that give us the rights to the source code for the software in our manufacturing equipment. It's not truly open-source, because we often will sign a non-disclosure agreement to satisfy the vendor's requirements, but we reserve the right to bring in outside consultants.
Of course, true open-source would be better for everyone in the long run, because companies that have equipment with similar functions or data handling requirements could leverage off of each other. I think it will take a while for that way of thinking to take hold in companies, though.
The goal of such software is not to make a profit on it, however (at least not directly). When people talk about "Open Source" or "Free Software" they are usually thinking about commercial applications. I agree with a previous poster that the way to make money in that arena is support. But even software released under the GPL can be sold for a price. The only restriction is the source code must be made available without additional cost. This usually has the effect of causing prices to be low (because the first customer who actually paid $$$ for it might share it for free, which is allowed under the GPL), but I can see a scenario where it doesn't for a limited distribution product (e.g. specialty CAD or simulation software).
Other licenses have other terms.
Here are two ways to do it:
/etc/fstab that designate swap partitions (insert a '#' at the front of the line). Upon next reboot, swap will not be used (you can also turn it off with swapoff). Remove the '#' to re-enable (reboot or swapon required).
1. To disable swap until you re-enable it, comment out any lines in your
2. To disable swap until the next reboot, just use the swapoff command: swapoff -a
To turn it back on, issue a swapon.