I don't suppose you've investigated the "None" cipher type, which as one might expect does not use any encryption but still provide the benefits of strong authentication? I thought not. There's no need to use the r-utilities, ever. Besides, if you've gone to the expense of building a Myrinet, you most likely care enough to write your own network communication routines and protocols for moving around the data you actually care about. Neither ssh nor r-* would be appropriate for performance-sensitive tasks in that type of environment.
Since ssh is a drop-in replacement for the r* utilities, the ideas will carry over from a discussion.
I certainly agree. However, this book is targeted at people new to administration. If this book discusses the r-utilities and not the s-utilities, which do you think its readers will use?
Why the personal attack? You had some actual arguments after this but I'm not going to bother responding to them with experiences I've had in my 7 years of Unix administration.
Don't remotely connect to the machine unless you control the entire network between the client and the new system. For practical purposes that means a crossover cable. A switched network is not good enough! So I strongly recommend doing the installation of ssh on the console if it's not included with your operating system. If OpenSSH has not been ported, buy a copy from the various proprietary vendors, or hire someone to port OpenSSH.
Another option is to put the unsupported sshless system next to a box that has ssh and use a serial cable or crossover network cable to connect them...insecure remote access over networks not under your exclusive control is insanity!
I haven't read the book, but the review says it includes a discussion of rlogin. Unless that discussion consists of "Do not use rlogin; use ssh instead" this book is obsolete. FACT: rlogin, rsh, rexec, and all other remote access utilities that do not perform cryptographically strong authentication and offer at least the option to encrypt the session are OBSOLETE. By extension, so is any book or document that considers such utilities viable.
If only this were still true. Every attempt to subvert this time-tested, proven design methodology has unleashed security problems of the most horrendous scale. Outlook attachments, anyone? In case it's not clear, the problem is that data (in this case a MIME attachment or similar) is treated as code and fed to the CPU. Sure, you can argue that it should ask first, but there will always be some way of defeating or subverting that. Data and code should be treated separately because they ARE separate. One can be meaningfully executed by a CPU, the other can't.
# Someone, or something, must remember the association between data in a given file, the action the user wishes to perform with/on that data, and the name of the file that contains the appropriate executable code.
Well, duh. A disk is a linear array of sectors, each with data or possibly code of some kind. It kind of goes without saying that someone or something has to remember what all that stuff is really for. Currently we have filesystems and files, but other mechanisms are surely possible. All of them however will fall into the general category of "someone or something remembering associations among goals, code, and data" even if it's some whiz-bang 3d data stream viewer.
The rule I always follow is to report bugs in software shipped by a vendor (ie RedHat, Debian, etc.) to that specific vendor rather than to the upstream maintainer directly. This is because vendors often apply their own patches to the canonical sources; these patches sometimes alter behaviour or locations in a way that would make the report meaningless to the authors. Of course, sometimes these patches also add or remove bugs themselves and are often the cause of the unexpected behaviour.
If a bug is major or affects security I will also mention it to the authors, especially if I'm feeling non-lazy and have reproduced the bug with the standard sources. And, of course, if I am using some software I built myself from the original sources, I will report the bug directly to the maintainer in all cases rather than my distribution vendor.
As a software author, it's often annoying when a distributor applies patches to software that add, remove, or change feature sets and may introduce additional bugs. Some maintainers will definitely not be willing to help you at all with packages built by others for this reason. Linux is a fine example - try asking sometime about the Red Hat kernel on LKML. Be prepared for flames and/or silence - after Red Hat applies their 500 patches nobody on that list will be willing even to look at your problem.
If you actually read the article for what it says rather than what you wanted it to say, you would know that the ice cap was formed during an extraordinarily wet period. That time has ended and the more recent dry conditions are the cause of the cap's disappearance. The ice wasn't there 12,000 years ago and it won't be there in 100 years because not enough snow is falling to replenish it.
To hear ecowackjobs tell it you'd assume there were humans around polluting 12,000 years ago and they all suddenly died off so that the ice cap could form. Jesus, people, the Earth changes all the time, sometimes wetter and sometimes drier, sometimes warmer and sometimes cooler, and sometimes in different ways in different places at the same time.
I am not a Republican. I do not drive a SUV. I am, however, a thinking man not prone to wild-eyed fanaticism over things I cannot claim to understand.
I want a high end "prosumer" IDE hard drive with a 5 year warranty.
Your "prosumer" drive is already offered. Check the shelf labeled "SCSI disks". The high-end server market is all fibrechannel with big backplanes and hundreds of high-speed highly redundant disks. The low-end Joe Six-pack market is all single-disk IDE. Single, software RAID, and single-controller hardware RAID SCSI are the prosumer options you're asking for. Don't bitch that they're more expensive - that's the whole point of midrange options; they're better, and more expensive.
The reason long warranties are no longer offered on IDE disks is that they're manufactured poorly using poor-quality components and corner-cutting processes. This is necessary because the consumer won't pay for anything better. If you want a longer warranty, you can either buy third-party insurance (probably silly) or pay the manufacturer more money to use better components and manufacturing processes. Well, the manufacturer already offers exactly what you're asking for - in the midrange disk line, with SCSI interfaces. This is done because, they reason, anyone who's willing to pay more for better quality and reliability would probably also like better performance and scalability, and maybe even compatibility with their high-end products. Therefore they put SCSI interfaces on these disks and give you those additional benefits.
Like so many others who suggest approach C, you have forgotten the Windows version of "DLL Hell" - a term coined not on the horrible, hated, source-aware Unix platoform (horrors!), but on your beloved pinnacle of proprietary progress, Windows itself. VBRUN100.DLL, anyone? Oops, I really needed VBRUN300.DLL. No, wait, installing *that* version makes SuperFoo98 crash! Woe, woe is me! "I installed a web browser and now my accounting software stopped working!" is not something I ever want to contemplate.
Also, all source distribution is not the opposite of all static linking. All source distribution and all binary distribution are opposites. Static linking is the opposite of dynamic linking. Both static and dynamic linking can cause problems.
In general, the proper approach for normal userland applications is dynamic linking with versioned symbols for preserving backward compatibility for existing binaries while offering new functionality to applications built against newer libraries. This is what glibc now does, and the approach has been a huge success. I remember the libc5 -> glibc2 transition. It was painful and ugly. It won't be necessary again thanks to versioned symbols.
Static linking is appropriate for applications which need to be functional when the rest of the system is not, for a sufficient portion of the kernel to be booted properly, and for most proprietary software (because proprietary vendors who link dynamically usually link against outdated libraries not likely to be present on modern systems).
The question of building from source versus binary package distribution is fairly unrelated to the question of dependencies - in either case if dependencies are not met the installation should notify the user and, according to the user's preferences, either automatically fetch and build or install the dependencies (apt, portage), ask the user what to do, or fail the installation with a descriptive indication of the problem, perhaps offering an explanation of how to eliminate the dependency if possible.
Again, to reiterate, distributing libraries with applications is not the proper solution. It bloats distributions, wastes bandwidth and disk space, causes conflicts among applications and libraries, generates mysterious and baffling interdependencies which should not exist among unrelated applications, and confuses users and administrators. In the best possible case, it requires each application to live in its own segregated world on the filesystem with custom startup scripts to ensure that the correct libraries are loaded. Even in this case, the benefits of dynamic linking (update your libraries without updating the applications using it) are discarded, and the additional startup scripts and distributed libraries require additional maintenance. This approach has been tried and has caused more problems than it solves.
Yes, that's right, every program on your disk should be statically linked. That way there will be no library dependencies. Also, when a small but crucial security fix in libc comes out, you get to reinstall your entire distribution instead of just libc. And, of course, since statically linked programs can't be overwritten on disk while they're running, updating any package will require tricks like the current libc upgrade process...well, that or we could do it the Microsoft way and just require lots of rebooting. As long as there are no dependencies, everything will be just fine.
Of course, there might still be a need for inter-program dependencies (for example, perl programs tend to work best when perl is installed) but in the interest of eliminating dependencies it's probably best to hide the fact from the user. The "command not found" messages that result in situations like that will undoubtedly alert the user to the fact that he or she should probably find and install the appropriate other package(s).
Duh. Apt and/or a Gentoo ports-like system are the answer to this type of problem. The security and flexibility edge goes to gentoo, for the USE variable - it allows me to not build (for example) PCRE support into Postfix if I don't want to install and depend on PCRE. Apt is easier and faster. Both are nice solutions to a common problem. As another example, Microsoft admins all seem to like the new Windows Update feature, for the exact same reasons we've all loved apt, ports, and gentoo for years - automatic updating of everything that needs updating with dependency resolution. Of course, our solutions are better because we don't force license-changing upgrades on users, but that's not a technical issue at all. For the time being, this type of solution is the best available for a problem faced by ALL computer administrators.
in the workplace were it makes a good programmer indistinguishable from a amateur wannabe
No. In the cube farms, or anywhere, incompetent programmers are easy to spot. They make obvious mistakes, reinvent the wheel, write twice or ten times the amount of code necessary to solve a problem. But most of all, the hallmark in any language of incompetent programmers is that the programs they write clearly show the mindset "I must be a great programmer; see how complicated my code can be?" The good programmers are lazy and like simple solutions in a minimum of code. The mindset reflected in their code is "I *am* a great programmer; my code shows how simple this problem really is." I guarantee you can always tell the difference.
Then how would you transfer large files from your shell account to your own system?
The assumption is that you wouldn't need to do so very often - you do most of your work in your shell account on the remote box, right? The thought process is that since you have so little bandwidth and probably less power, disk space, memory, etc. at home that there's not much point in using that computer as anything but a glass terminal, and doing interesting things only on the remote system.
So the value of the shell account is inversely proportional to the power, capacity, connectivity, and quality of maintenance of your own hosts. For many people, that value ends up being fairly high. That's especially true if one wishes to let someone else take care of building, patching, installing, and upgrading software, doing regular tape backups, providing security precautions and responding to incidents, responding to postmaster mail, and in short performing the dull and time-consuming tasks of managing hosts (and participating properly in the Internet community).
The shell account is the network pc taken one step further, and is effective even with fairly slow networks. Still, if you didn't think thin client computing was a good idea, you probably don't find shell accounts useful either. Judging by the marketplace response, I'm about the only person who sees much merit in either.
What other kind would be needed? From a shell account you can do pretty much anything. With the appropriate permissions you could also run pppd and extend the network, for example. You can run servers, read mail, send mail, transfer files around, develop software, and so on.
Yes, you could do most of those things on your own system, but chances are pretty good that you have less bandwidth. This is especially true if you can only afford or only have access to dialup network access.
OSS always makes a replacement, but it is only 98% there in terms of functionality in most cases.
Actually it is 180% of the functionality and 500% of the quality but might be missing one or two stupid features that the authors decided not to implement because it's stupid/useless/insecure/whatever, that the CEO fell in love with. There are plenty of non-Exchange calendaring solutions. There are plenty of mail solutions that exceed Exchange in every way - features, performance, and reliability. But they're not Exchange, and fuckwit CEOs aren't smart enough to grasp the idea of using non-Microsoft software.
Don't waste your time trying to write software that replaces [X] in the general case. The people you are trying to reach with it won't be receptive. They don't want the functionality or performance or other characteristics [X]; what they really want is the fact that it *IS* [X]. By definition nothing you write will be [X] and therefore only a few percent of the target market will be interested. Do not attempt to sell anything to fools based on its merit. Instead, take up golf and consider offering kickbacks.
If you are going to write software, write software that meets a need FOR YOU. You know, do it the way that got us here. Trying to rewrite Exchange in all it's bloated, slow, insecure glory just so that someone at Stupidity, Inc. will use it is pointless unless you work for Stupidity Inc. After all, if you wanted Exchange, you'd use it. Since you don't, why would you want to write it?
So either write something new that will be its own [X], or write or contribute to something that competes with [X] on its own terms, by offering different functionality, better performance, or other features that are more useful to you. There's no point in reinventing the wheel to take away someone else's market share.
The company gains a level of control over the persons personal life that is anathema to the basic freedoms modern workers should expect.
That's a problem for American citizens, too. It makes the H1B visa holders unfair competition for American workers. If H1B holders had the same freedom as citizens (ie if they had actual green cards) then their employers would have to pay better wages and in general offer greater compensation or less work. In short, the indentured servitude factor hurts American workers almost as much as it hurts the H1B holders. For that reason, the previous poster who advocated fast-tracking H1Bs to green cards makes a lot of sense to me. It gives them a greater stake in the country, making them more likely to stay (keeping their skills here rather than returning to their homelands), offers them a better future, and at the same time helps to ensure a more level playing field for everyone. If the only reason a foreign worker isn't employed here is that he or she is foreign, the solution is to issue a green card. But if Americans are out of work only because Evil Inc. can force that foreign worker to work for 40% less than his counterparts, the situation is out of hand and the government, NOT THE H1B HOLDERS, is to blame.
Give employers of current H1B holders a choice - they can:
Pay the government and the worker $10,000 each per year of previous employment and in exchange the government will issue him or her a green card, or
Send the H1B worker home within 60 days.
This will mean that the best foreign workers will be on track to citizenship and the worst will be sent home to make room for local workers. It's simple economics - is Satish really as good as Jane? If he is, why are you paying him less? And, do you want to keep him and pay, or send him home and replace him with someone more expensive? Either way it forces companies to pay the true cost of doing business in the US. If that's too high, we'll see relocations offshore...but that's pretty much unavoidable in any case and it happens already.
If the law only requires that I "suspect" or "believe" that someone is using my works unlawfully, I can easily send a letter to the head of the MPAA with a legend indicating that it is for his eyes only. Since secretaries and underlings read all normal mail headed for such people, they'll be in violation of my copyright (I haven't given him the right to distribute the letter to his underlings) and I can initiate a DDoS on this basis of suspicion. Really, this is flimsy and contrived, but it highlights the stupidity of the legislation.
Much better would be if, for the protection of infrastructure, all major ISPs drop packets from ??AA-controlled networks at their borders. Since ISPs are not obligated to carry any traffic other than that of their customers, and they are obligated to their own shareholders to protect and preserve their own infrastructure, they are essentially required to drop traffic from locations they may reasonably expect to be sources of attacks against their own or their customers' networks. Whether the attacks are legal or not, the ISPs still have a compelling business interest in preventing them.
The logic that spam must work if it's continuing is the same as saying that the dot-coms were bound to succeed or else the VCs wouldn't keep investing. Sometimes people do stupid things. And, as others have mentioned, spam is probably the cheapest form of advertising available today (for the advertiser). No, I don't know who buys penis pills or badly-remanufactured laser printer cartridges either. Even if nobody does, these spammers don't have any business incentive to stop.
Open source isn't always a good idea, it depends entirely on the circumstances.
I happen to disagree, but even if I didn't I'd suggest that this is one of the times when having the source code is most important.
The US federal government is not a trustworthy entity. Various departments within that organisation are known to disregard laws concerning privacy and security and many of these also have institutional goals, official or otherwise, that involve spying on American citizens and others. Therefore a reasonable person would consider binary-only software from the federal government to be untrusted in the same way as an unsolicited mail attachment or unsigned binary files found on arbitrary web or ftp sites. The reasonable and prudent assumption is that such untrusted binaries are malware until proven otherwise.
If the government wants to convince systems administrators that its security-enhancing software is in fact *not* malware, the best way would be to provide the source code in full. If doing so exposes new vulnerabilities, the government should, before releasing the tools in any form, follow normal vulnerability reporting procedures. If Microsoft or other vendors are unresponsive, the proper procedure includes full disclosure of the vulnerabilities and their fixes. The source code to these tools constitute fixes, and should be released either in coordination with vendors or in the event that vendors are unresponsive. In short, the government should follow the same procedures regarding vulnerability disclosure and dissemination that most other people do.
Internally, of course, I expect and hope that systems would be patched as soon as possible. Naturally I would patch my own company's systems even before a vendor releases a patch if I initially discovered the problem and its solution. But internal dissemination is a separate matter.
Have to disagree. Nvidia's drivers crashed my box hard at least a few times a week - even when I wasn't using GLX apps. Since I replaced the card with an ATI and started using the stock XFree drivers, no crashes. Imagine that. And, yes, I did use the very latest nvidia drivers. But then, it's hardly unusual for binary-only stuff to crash; I almost never have problems with anything I've built myself but any binaries from elsewhere seem to be highly crash-prone. So no thanks to that. The ATI card is plenty fast and X doesn't crash on me so I'll stay with it.
I agree, and I disagree. True, it's very hard to support unknown configurations and unknown software on a customer's system. However, my ISP will support me pretty much regardless of what I'm running. The kicker? I need to convince them that whatever problem I'm having is theirs or at least that I'm not being blatantly stupid. They probably won't teach me ifconfig syntax, but they'll surely tell me what my gateway needs to be on their network. The important point here is that I know enough to ask.
I really like this ISP precisely because they provide such excellent support, and won't just hang up on me if they hear that I'm not using the latest Redmond-approved OS. Obviously, there are times when they have to tell people that they can't possibly support every possible CPE configuration, but they make a strong effort to help the technically clued even when they may not be using 100%-standard software. This type of effort distinguishes them from their competitors and has earned them my business. I won't hold it against ISPs who will only support a small number of standard configurations, because I understand what's needed to go beyond that, but I also won't do business with them.
How about:...
else if SO
assert (get_temperature (HELL) 10);
endif
Why imagine something that will never happen? And hey, I'm 23. If you haven't woken to a lover's voice by 23, you never will. Pathetic? *shrug* C'est la vie.
If you weren't a troll, I'd point out that they've openly discussed their architecture in the past and their use of Linux is well-known. But since you are a troll, I won't put much effort into it. I wouldn't want to feed you, after all.
Typical Mac idiot. Forward and backward compatible CPUs started much longer in the past. The 680x0 are all backward-compatible. The transition from SPARC v7 to v8 and then to 64-bit v9 also left userland applications fully compatible across the full range of CPUs. MIPS CPUs starting with the R4000 have 64-bit capabilties but can actually run either 32-bit or 64-bit operating systems and userland. There are plenty of other examples dating back 10-20 years or longer of large changes, including register length and pointer size, made to architectures without breaking existing user applications (in some cases without breaking existing operating systems). G4 is a latecomer to this game, as are these offerings from Inhell and AMD.
Slashdot Mirror
I don't suppose you've investigated the "None" cipher type, which as one might expect does not use any encryption but still provide the benefits of strong authentication? I thought not. There's no need to use the r-utilities, ever. Besides, if you've gone to the expense of building a Myrinet, you most likely care enough to write your own network communication routines and protocols for moving around the data you actually care about. Neither ssh nor r-* would be appropriate for performance-sensitive tasks in that type of environment.
I certainly agree. However, this book is targeted at people new to administration. If this book discusses the r-utilities and not the s-utilities, which do you think its readers will use?
Why the personal attack? You had some actual arguments after this but I'm not going to bother responding to them with experiences I've had in my 7 years of Unix administration.
Another option is to put the unsupported sshless system next to a box that has ssh and use a serial cable or crossover network cable to connect them...insecure remote access over networks not under your exclusive control is insanity!
I haven't read the book, but the review says it includes a discussion of rlogin. Unless that discussion consists of "Do not use rlogin; use ssh instead" this book is obsolete. FACT: rlogin, rsh, rexec, and all other remote access utilities that do not perform cryptographically strong authentication and offer at least the option to encrypt the session are OBSOLETE. By extension, so is any book or document that considers such utilities viable.
If only this were still true. Every attempt to subvert this time-tested, proven design methodology has unleashed security problems of the most horrendous scale. Outlook attachments, anyone? In case it's not clear, the problem is that data (in this case a MIME attachment or similar) is treated as code and fed to the CPU. Sure, you can argue that it should ask first, but there will always be some way of defeating or subverting that. Data and code should be treated separately because they ARE separate. One can be meaningfully executed by a CPU, the other can't.
# Someone, or something, must remember the association between data in a given file, the action the user wishes to perform with/on that data, and the name of the file that contains the appropriate executable code.
Well, duh. A disk is a linear array of sectors, each with data or possibly code of some kind. It kind of goes without saying that someone or something has to remember what all that stuff is really for. Currently we have filesystems and files, but other mechanisms are surely possible. All of them however will fall into the general category of "someone or something remembering associations among goals, code, and data" even if it's some whiz-bang 3d data stream viewer.
If a bug is major or affects security I will also mention it to the authors, especially if I'm feeling non-lazy and have reproduced the bug with the standard sources. And, of course, if I am using some software I built myself from the original sources, I will report the bug directly to the maintainer in all cases rather than my distribution vendor.
As a software author, it's often annoying when a distributor applies patches to software that add, remove, or change feature sets and may introduce additional bugs. Some maintainers will definitely not be willing to help you at all with packages built by others for this reason. Linux is a fine example - try asking sometime about the Red Hat kernel on LKML. Be prepared for flames and/or silence - after Red Hat applies their 500 patches nobody on that list will be willing even to look at your problem.
To hear ecowackjobs tell it you'd assume there were humans around polluting 12,000 years ago and they all suddenly died off so that the ice cap could form. Jesus, people, the Earth changes all the time, sometimes wetter and sometimes drier, sometimes warmer and sometimes cooler, and sometimes in different ways in different places at the same time.
I am not a Republican. I do not drive a SUV. I am, however, a thinking man not prone to wild-eyed fanaticism over things I cannot claim to understand.
Your "prosumer" drive is already offered. Check the shelf labeled "SCSI disks". The high-end server market is all fibrechannel with big backplanes and hundreds of high-speed highly redundant disks. The low-end Joe Six-pack market is all single-disk IDE. Single, software RAID, and single-controller hardware RAID SCSI are the prosumer options you're asking for. Don't bitch that they're more expensive - that's the whole point of midrange options; they're better, and more expensive.
The reason long warranties are no longer offered on IDE disks is that they're manufactured poorly using poor-quality components and corner-cutting processes. This is necessary because the consumer won't pay for anything better. If you want a longer warranty, you can either buy third-party insurance (probably silly) or pay the manufacturer more money to use better components and manufacturing processes. Well, the manufacturer already offers exactly what you're asking for - in the midrange disk line, with SCSI interfaces. This is done because, they reason, anyone who's willing to pay more for better quality and reliability would probably also like better performance and scalability, and maybe even compatibility with their high-end products. Therefore they put SCSI interfaces on these disks and give you those additional benefits.
Also, all source distribution is not the opposite of all static linking. All source distribution and all binary distribution are opposites. Static linking is the opposite of dynamic linking. Both static and dynamic linking can cause problems.
In general, the proper approach for normal userland applications is dynamic linking with versioned symbols for preserving backward compatibility for existing binaries while offering new functionality to applications built against newer libraries. This is what glibc now does, and the approach has been a huge success. I remember the libc5 -> glibc2 transition. It was painful and ugly. It won't be necessary again thanks to versioned symbols.
Static linking is appropriate for applications which need to be functional when the rest of the system is not, for a sufficient portion of the kernel to be booted properly, and for most proprietary software (because proprietary vendors who link dynamically usually link against outdated libraries not likely to be present on modern systems).
The question of building from source versus binary package distribution is fairly unrelated to the question of dependencies - in either case if dependencies are not met the installation should notify the user and, according to the user's preferences, either automatically fetch and build or install the dependencies (apt, portage), ask the user what to do, or fail the installation with a descriptive indication of the problem, perhaps offering an explanation of how to eliminate the dependency if possible.
Again, to reiterate, distributing libraries with applications is not the proper solution. It bloats distributions, wastes bandwidth and disk space, causes conflicts among applications and libraries, generates mysterious and baffling interdependencies which should not exist among unrelated applications, and confuses users and administrators. In the best possible case, it requires each application to live in its own segregated world on the filesystem with custom startup scripts to ensure that the correct libraries are loaded. Even in this case, the benefits of dynamic linking (update your libraries without updating the applications using it) are discarded, and the additional startup scripts and distributed libraries require additional maintenance. This approach has been tried and has caused more problems than it solves.
Of course, there might still be a need for inter-program dependencies (for example, perl programs tend to work best when perl is installed) but in the interest of eliminating dependencies it's probably best to hide the fact from the user. The "command not found" messages that result in situations like that will undoubtedly alert the user to the fact that he or she should probably find and install the appropriate other package(s).
Duh. Apt and/or a Gentoo ports-like system are the answer to this type of problem. The security and flexibility edge goes to gentoo, for the USE variable - it allows me to not build (for example) PCRE support into Postfix if I don't want to install and depend on PCRE. Apt is easier and faster. Both are nice solutions to a common problem. As another example, Microsoft admins all seem to like the new Windows Update feature, for the exact same reasons we've all loved apt, ports, and gentoo for years - automatic updating of everything that needs updating with dependency resolution. Of course, our solutions are better because we don't force license-changing upgrades on users, but that's not a technical issue at all. For the time being, this type of solution is the best available for a problem faced by ALL computer administrators.
No. In the cube farms, or anywhere, incompetent programmers are easy to spot. They make obvious mistakes, reinvent the wheel, write twice or ten times the amount of code necessary to solve a problem. But most of all, the hallmark in any language of incompetent programmers is that the programs they write clearly show the mindset "I must be a great programmer; see how complicated my code can be?" The good programmers are lazy and like simple solutions in a minimum of code. The mindset reflected in their code is "I *am* a great programmer; my code shows how simple this problem really is." I guarantee you can always tell the difference.
The assumption is that you wouldn't need to do so very often - you do most of your work in your shell account on the remote box, right? The thought process is that since you have so little bandwidth and probably less power, disk space, memory, etc. at home that there's not much point in using that computer as anything but a glass terminal, and doing interesting things only on the remote system.
So the value of the shell account is inversely proportional to the power, capacity, connectivity, and quality of maintenance of your own hosts. For many people, that value ends up being fairly high. That's especially true if one wishes to let someone else take care of building, patching, installing, and upgrading software, doing regular tape backups, providing security precautions and responding to incidents, responding to postmaster mail, and in short performing the dull and time-consuming tasks of managing hosts (and participating properly in the Internet community).
The shell account is the network pc taken one step further, and is effective even with fairly slow networks. Still, if you didn't think thin client computing was a good idea, you probably don't find shell accounts useful either. Judging by the marketplace response, I'm about the only person who sees much merit in either.
Yes, you could do most of those things on your own system, but chances are pretty good that you have less bandwidth. This is especially true if you can only afford or only have access to dialup network access.
Actually it is 180% of the functionality and 500% of the quality but might be missing one or two stupid features that the authors decided not to implement because it's stupid/useless/insecure/whatever, that the CEO fell in love with. There are plenty of non-Exchange calendaring solutions. There are plenty of mail solutions that exceed Exchange in every way - features, performance, and reliability. But they're not Exchange, and fuckwit CEOs aren't smart enough to grasp the idea of using non-Microsoft software.
Don't waste your time trying to write software that replaces [X] in the general case. The people you are trying to reach with it won't be receptive. They don't want the functionality or performance or other characteristics [X]; what they really want is the fact that it *IS* [X]. By definition nothing you write will be [X] and therefore only a few percent of the target market will be interested. Do not attempt to sell anything to fools based on its merit. Instead, take up golf and consider offering kickbacks.
If you are going to write software, write software that meets a need FOR YOU. You know, do it the way that got us here. Trying to rewrite Exchange in all it's bloated, slow, insecure glory just so that someone at Stupidity, Inc. will use it is pointless unless you work for Stupidity Inc. After all, if you wanted Exchange, you'd use it. Since you don't, why would you want to write it?
So either write something new that will be its own [X], or write or contribute to something that competes with [X] on its own terms, by offering different functionality, better performance, or other features that are more useful to you. There's no point in reinventing the wheel to take away someone else's market share.
That's a problem for American citizens, too. It makes the H1B visa holders unfair competition for American workers. If H1B holders had the same freedom as citizens (ie if they had actual green cards) then their employers would have to pay better wages and in general offer greater compensation or less work. In short, the indentured servitude factor hurts American workers almost as much as it hurts the H1B holders. For that reason, the previous poster who advocated fast-tracking H1Bs to green cards makes a lot of sense to me. It gives them a greater stake in the country, making them more likely to stay (keeping their skills here rather than returning to their homelands), offers them a better future, and at the same time helps to ensure a more level playing field for everyone. If the only reason a foreign worker isn't employed here is that he or she is foreign, the solution is to issue a green card. But if Americans are out of work only because Evil Inc. can force that foreign worker to work for 40% less than his counterparts, the situation is out of hand and the government, NOT THE H1B HOLDERS, is to blame.
Give employers of current H1B holders a choice - they can:
- Pay the government and the worker $10,000 each per year of previous employment and in exchange the government will issue him or her a green card, or
- Send the H1B worker home within 60 days.
This will mean that the best foreign workers will be on track to citizenship and the worst will be sent home to make room for local workers. It's simple economics - is Satish really as good as Jane? If he is, why are you paying him less? And, do you want to keep him and pay, or send him home and replace him with someone more expensive? Either way it forces companies to pay the true cost of doing business in the US. If that's too high, we'll see relocations offshore...but that's pretty much unavoidable in any case and it happens already.Much better would be if, for the protection of infrastructure, all major ISPs drop packets from ??AA-controlled networks at their borders. Since ISPs are not obligated to carry any traffic other than that of their customers, and they are obligated to their own shareholders to protect and preserve their own infrastructure, they are essentially required to drop traffic from locations they may reasonably expect to be sources of attacks against their own or their customers' networks. Whether the attacks are legal or not, the ISPs still have a compelling business interest in preventing them.
The logic that spam must work if it's continuing is the same as saying that the dot-coms were bound to succeed or else the VCs wouldn't keep investing. Sometimes people do stupid things. And, as others have mentioned, spam is probably the cheapest form of advertising available today (for the advertiser). No, I don't know who buys penis pills or badly-remanufactured laser printer cartridges either. Even if nobody does, these spammers don't have any business incentive to stop.
I happen to disagree, but even if I didn't I'd suggest that this is one of the times when having the source code is most important.
The US federal government is not a trustworthy entity. Various departments within that organisation are known to disregard laws concerning privacy and security and many of these also have institutional goals, official or otherwise, that involve spying on American citizens and others. Therefore a reasonable person would consider binary-only software from the federal government to be untrusted in the same way as an unsolicited mail attachment or unsigned binary files found on arbitrary web or ftp sites. The reasonable and prudent assumption is that such untrusted binaries are malware until proven otherwise.
If the government wants to convince systems administrators that its security-enhancing software is in fact *not* malware, the best way would be to provide the source code in full. If doing so exposes new vulnerabilities, the government should, before releasing the tools in any form, follow normal vulnerability reporting procedures. If Microsoft or other vendors are unresponsive, the proper procedure includes full disclosure of the vulnerabilities and their fixes. The source code to these tools constitute fixes, and should be released either in coordination with vendors or in the event that vendors are unresponsive. In short, the government should follow the same procedures regarding vulnerability disclosure and dissemination that most other people do.
Internally, of course, I expect and hope that systems would be patched as soon as possible. Naturally I would patch my own company's systems even before a vendor releases a patch if I initially discovered the problem and its solution. But internal dissemination is a separate matter.
Have to disagree. Nvidia's drivers crashed my box hard at least a few times a week - even when I wasn't using GLX apps. Since I replaced the card with an ATI and started using the stock XFree drivers, no crashes. Imagine that. And, yes, I did use the very latest nvidia drivers. But then, it's hardly unusual for binary-only stuff to crash; I almost never have problems with anything I've built myself but any binaries from elsewhere seem to be highly crash-prone. So no thanks to that. The ATI card is plenty fast and X doesn't crash on me so I'll stay with it.
that we will run out of salt. Move along, nothing new here.
I really like this ISP precisely because they provide such excellent support, and won't just hang up on me if they hear that I'm not using the latest Redmond-approved OS. Obviously, there are times when they have to tell people that they can't possibly support every possible CPE configuration, but they make a strong effort to help the technically clued even when they may not be using 100%-standard software. This type of effort distinguishes them from their competitors and has earned them my business. I won't hold it against ISPs who will only support a small number of standard configurations, because I understand what's needed to go beyond that, but I also won't do business with them.
How about: ...
else if SO
assert (get_temperature (HELL) 10);
endif
Why imagine something that will never happen? And hey, I'm 23. If you haven't woken to a lover's voice by 23, you never will. Pathetic? *shrug* C'est la vie.
If you weren't a troll, I'd point out that they've openly discussed their architecture in the past and their use of Linux is well-known. But since you are a troll, I won't put much effort into it. I wouldn't want to feed you, after all.
Typical Mac idiot. Forward and backward compatible CPUs started much longer in the past. The 680x0 are all backward-compatible. The transition from SPARC v7 to v8 and then to 64-bit v9 also left userland applications fully compatible across the full range of CPUs. MIPS CPUs starting with the R4000 have 64-bit capabilties but can actually run either 32-bit or 64-bit operating systems and userland. There are plenty of other examples dating back 10-20 years or longer of large changes, including register length and pointer size, made to architectures without breaking existing user applications (in some cases without breaking existing operating systems). G4 is a latecomer to this game, as are these offerings from Inhell and AMD.