First, we were discussing "modern operating systems" which I took to mean your typical desktop systems from this millennium rather than things like crays and even clusters.
Second, I'm under the impression supercomputers do not multi-task, so there would never be anything to swap in the first place (or if there were, it would be hand-written by the specific app.
Linux kernel maintainer Andrew Morton sets his swappiness to 100 (page as much physical memory as you can, the opposite of this Ask-Slashdot's desires), which he justified in an interview (see above link) by saying:
My point is that decreasing the tendency of the kernel to swap stuff out is wrong. You really don't want hundreds of megabytes of BloatyApp's untouched memory floating about in the machine. Get it out on the disk, use the memory for something useful.
Of course, there's another view, also presented at the above kerneltrap article: If you swap everything, you'll have a very long wait when returning to something you haven't touched in a while.
If you have limited resources, milk the resources you have plenty of; workstations should have high swappiness while laptops, who suffer in disk speed, disk capacity, and power, are probably better suited with lower swappiness. Don't go crazy, though... swappiness = 0 is the same as running swapoff -a and will crash your programs when they need more memory than is available (as the kernel isn't written for a system without swap).
I recall back in 2002 or so, a friend of mine maxed out his Windows XP system with 2gb of memory. Windows absolutely refused to turn off paging (swap), forcing him to whatever the minimum size was. The solution? He created a RAMdisk and put the paging file there.
On Linux (and other modern systems, perhaps now including Windows), you can turn off swap. However, the Linux kernel's memory management isn't so great at the situation you hit when you need more memory than you have, but you can't swap. Usually, the memory hog crashes as a result (thankfully, Firefox now has session restore). I might be slightly out of date on this one.
A well-tweaked system still has swap (in nontrivial amounts), but rarely uses it. Trust me, you can afford losing the few gigabytes from your filesystem. Again in Linux,/proc/sys/vm/swappiness can be tweaked to a percentage reflecting how likely the system is to swap memory. Just lower it. (Though note the cons to this presented at the kerneltrap article above.) My workstation currently has an uptime of 14 days, a swappiness of 60, and 42/1427 megs of swap in use as opposed to the 1932/2026 megs of physical memory in use at the moment.
This is summarized for Windows and Linux on Paging at Wikipedia.
I got so entangled in defending my joke assumption that I forgot one of the real reasons I liked Kaspersky's headquartering in Russia: It's not in America or any of its corporation-friendly, overprotective, terrorist-fearing peers, and it's not in a nation that is easily bullied by America, its peers, or corporations.
This means it doesn't need some "Homeland Security" back-door, it doesn't need to turn a blind eye to corporate root-kits and other DRM-enforcers, and it can be harsh on corporate spyware.
You'll find crap in any of the vendors. Hell, the whole industry is a con; this is one of the few items that actually SHOULD be bundled into the operating system (IMHO), and the fact that Windows Update doesn't have it built-in is a comedic result of the anti-trust issues Microsoft has earned from its abuse of that concept in other areas.
Yes, Kaspersky's defaults on those two areas are stupid. Fortunately for my company, I can change that on the server so that new installs never need to worry about it. The fact that AdminKit uses MMC rather than its own UI is also host to a ton of issues, and I'm still waiting for a web-based administration option (like with Trend Micro, but hopefully without requiring ActiveX).
I never did understand hosting mail on a Windows server... Exchange may be nice, but I don't intend to ever find out.
NOD32, BitDefender, and Avira all look just as viable as Kaspersky. I'm sure each one has its own baggage. Good luck.
Ignoring the assumption that all viruses come from Russia, wouldn't that make it more likely that the virus developers would make sure their viruses can evade detection under it?
First, that assumption was a joke. My humblest apologies if that offended anybody. Second, it's a common practice to not "pee in your own pool," which is to say that viruses are written for a target, which should not include the writers' personal systems (since they know better). The assumption that I am making is that this target is more likely to be one or more of the top three anti-virus solutions (McAfee, Symantec, Trend Micro).
Furthermore, the areas Kaspersky is developed and popular in could be viewed as having a larger number of people who may have had sophomoric experience writing viruses but who have since reformed. That means that their personal background might make them quite qualified to choose an anti-virus solution. It also means that Kaspersky has a better pool of applicants when hiring developers than the competition.
I can also attest to the results of Soviet education helping here; my company's offshore developers in ex-Soviet regions are very well prepared for software development. I have friends and I've had (on-shore) co-workers who also fit this bill.
This article (at Mongabay, not Science) starts out strong, saying "accessible and unpolluted freshwater is a necessity for every nation's stability and well-being." Unfortunately, that first sentence was the last reference in the article to the issue of pollution or non-salt contamination.
What we really need is the ability to farm directly in the ocean without producing inedible food. The article's referenced halophytes (plants that can grow in salt water) are just one piece of the issue, as the ocean is also filled with other contaminants (mercury, industrial waste, and so very much more). We can probably do some farming with net-like filters around enclosed areas (similar to the way most fish farming works). Wikipedia calls this "open cage aquaculture." However, these filters can only get so much, and once you get complex enough to need a treatment facility, you've defeated the purpose of farming in the ocean (unless you treat the whole ocean...).
We use Kaspersky for Windows systems at work (and ClamAV on Linux for mail, though that might change to Kaspersky as I believe we have a license for it). When employees ask if they can use our licenses for their personal machines, I point them at Avira AntiVir because it's about as good and it's FREE FOR PERSONAL USE (although the free version has less spyware detection). It blows AVG out of the water.
Here are some useful links from my research, which included the above site:
Virus Bulletin's latest test results (no direct ranking).
From the Wikipedia links and other research that I didn't bother to note to my colleagues (who were also doing this research), I determined that Kaspersky's software was among the most efficient and CPU-friendly. It's only downside was a less-than-optimal user interface, especially on the administrative side for the corporate product. We didn't mind its UI flaws in the free trial period, so we purchased it. We're still happy with it several months later.
The main arguments for our switching from Trend Micro were that it was slow, had poor performance, missed several viruses, we wanted to boycott it, and we were tied to a very old version (since it out-performs the newer ones in reviews). Arguments for switching to Kaspersky included: it doesn't feel bloated (remember when that was the norm?), great performance, well received across the board in reviews, dirt cheap (new licenses are 70% the current renewal cost of Trend Micro, which is an ever-growing target), we liked the UI that prevented reviewers from giving it a perfect score, and it's the de-facto number one scanner in Russia and surrounding area (you know, where all the viruses come from?). Kaspersky is also growing rapidly in deployments; you can now get computers installed with it.
A certificate-based login (which you can play with at www.cacert.org) would solve this problem. When you initially set it up with your bank, they should require gobs of information proving your identity (full card number, CCV, address, social security number, and last ATM transaction data should suffice), and then they'll let you generate a key for your browser. This easily qualifies as "something you have" for two-factor authentication without needing anything silly like a USB key that would cost the bank money on a per-key basis in time and resources. (Footnote: This isn't as well documented as it should be; your best bet is to play with cacert.org's free implementation. There's tidbits of it in Wikipedia's TLS article, and cacert's wiki has a decent Client Certs page that says a little more.)
After that, you'll need that key plus the tools already employed. Most banks these days already have interesting ways to prove their own identity to you (they supply you with an image and some secret text you agreed upon earlier), then they have some clever input mechanism that tries to bypass keyloggers and javascript hacks.
Also recall that banks are VERY good about locking your account; a properly protected four-digit number is actually secure enough if you're only allowed two failed logins per day (regardless of source) since the code would take up to 5000 days (13+ years) to crack, and I'm sure there are further safeguards for that kind of case.
To banking software firms: I would immediately switch* to an online bank that performs this configuration. So would others. Don't forget: people like me are consulted regularly by family and social networks for advice about this very topic. (* Assuming the bank is FDIC/NCUA-insured, otherwise well-received and regarded, and fully pays for a few ATM usage fees each month).
First and foremost, like all the other posts here, I'll tell you that you should not pursue legal advice from blogs like Slashdot. Even if people here claim to be lawyers, they likely are not, and even if they actually are, you are NOT being given legal advice (in the best case, you're getting their hasty first impressions).
Second: Such ownership rights are usually solidified upon employment by means of signing some kind of contract that agrees on who will own what. Without that, there may still be precedents for one way or another, but there may be enough ambiguity to work out a compromise that is favorable to all involved parties.
Offer to give them the copyright in exchange for an "non-exclusive infinite license" (that is not a legal term), effectively entitling you to use it outside the courtroom as if you had copyright, so you could sell licenses, GPL it, etc. If that's too strong (or more than you want), ask for a GPL, AGPL, or LGPL (the first two preserve the profitability of the copyright, since closed-source software is considerably more salable). They still get to use it however they like as the copyright holders, and your Free Software use probably won't get in their way anyway. If you think they'd be game for it, start the haggling in the other direction -- offer them the infinite license. If they take that, you'll probably have to include some kind of clause covering what happens if legal action is needed to protect it, as the copyright holder is the only party that can act on that (which is why the FSF requires copyright attribution for all GNU projects).
If you want FREE legal advice, you may be able to ask the Software Freedom Law Center (SFLC) for it at http://www.softwarefreedom.org/
It appears BruteForceBlocker is a decent BSD implementation of fail2ban. However, it lacks the flexibility; from what I can see, all it does is notice a failed login and forever block the offending IP, which screws users who accidentally forgot to include the ssh key, or who used the wrong user name accidentally.
Fail2ban actually bans the offending IP after several failed authentications within a small window of time, and the ban is only for a small window of time... the purpose is not defensive for security, but rather for bandwidth preservation; it's okay for somebody to try a few pokes here and there, just not a flurry of them.
The only bit that BruteForceBlocker has that fail2ban does not is that of the reporting and checking mechanism, which appears to be a recent addition. I don't see any indication that the blocklist is a well-groomed and up-to-date list, which is huge problem, as most of the IPs used by botnets are dynamic, and any one of them could be cleaned or re-allocated for legitimate use in the future. This lends itself to the same issues as your typical DNSBLs, which is why I proposed such a thing over a more generic blacklist.
Given the issue with maintenance, I'd stay clear of that feature. It might be useful for sharing temporary blocklists between your own servers, but you must be sure to rotate them periodically so that they do not grow stale.
That brings me to the next issue - efficiency. I don't know too much about the inner workings of pf or iptables, but if you have a poorly implemented filter hosting a lookup table with tens of thousands of IPs to check against, you're going to slow your system's entire internet traffic pipe considerably.
"Reincarnate" means To cause to be reborn in another body; incarnate again (ADHD, Dictionary.com)... as in you die and the next thing you know, you're alive but in somebody else's body. The process in question here is actually "resurrecting," "raising," or, as TFA actually states, "bringing back" the dead, but only a clinical definition of "death" that doesn't mean dead in the sense that they're not coming back. Only the HTML title of the article (and the slashdot post title) use this horribly flawed term.
Rather, this appears to be suspended animation, which frankly I find more interesting anyway. While you're suspended, you're clinically "dead," which is a state we can already induce with various toxins (supposedly, with intense meditation, yogis can do this as well).
Disable root access: in/etc/ssh/sshd_config, set PermitRootLogin no
Disable password access (require ssh keys!): in/etc/ssh/sshd_config, set PasswordAuthentication no
Use an auto-banning solution like Fail2ban to limit attacking traffic and save bandwidth
SSH keys ensure that you're virtually immune to attacks, since the attack now MUST be brute-force (or break the RSA/DSA algorithms or compromise the server itself rather than an account), and must crack a "password" of over 150 base64 characters representing the 1024 bits of entropy in the key; a completely random printable password of 20 characters has 130 bits of entropy and an 8-word Diceware passphrase has only 120; you're not brute-forcing that.
Preventing root from accessing remotely is just smart (your logs can show who really logged in, your sudo logs show who needed root-level access and when, and you can auto-ban root logins immediately rather than after a set number of failed authentications).
All we're missing is the extension to #3 to handle distributed attack failures (as proposed by the parent post); with the proper protections, this is a bandwidth issue rather than a security issue (unless you're worried about DDoS, but we're talking about low-intensity attacks here).
For those of you stuck permitting passwords, you'll want something like John the Ripper to brute-force users' insecure passwords before the enemies do. This way you can disable their accounts when you find that they are vulnerable and force them to change their password to something more secure.
I use Fail2ban on all of my iptables-based SSH servers, as it eliminates the possibility of brute-force attacks from single IPs (fail2ban will ban any IP with five failed ssh logins in a ten minute period. The ban vanishes after ten minutes).
However, this new botnet attack distributes the attack over the IP-space and time. That bypasses fail2ban!
The only solution I can see to this would be to take an approach similar to the centralized spam-fighting solutions; a DNSBL specialized for brute-force botnets. You run something that monitors your logs for failed logins (with a large scope for time, say ten failed attempts in a month). When an IP triggers it, you block that IP for a month and report it to the DNSBL. The DNSBL operates like Spamcop, trying to verify the nature of the IP (and trying to address the issue), then adding it to the blocklist. Anything listed on a DNSBL gets permanently blocked after one failed authentication, and if your internal list grows too big, any positive IP gets blocked before the login attempt.
Yeah, looks like I missed that one. You and two ACs pointed that out... oops. I'm not really exposed to MS server stuff outside the Active Directory realm these days, and my social networking seems to have stagnated in the MS world; I used to have a number of friends who were in the ASP.NET camp, but most of them converted to other things (rails, j2ee, cakePHP, and non-web development with C#) and I lost track of some of them, too.
Yahoo represents the "old web" that Google is beating the pants off of. I wouldn't be surprised if Microsoft/MSN's own resources are as good or better. What Microsoft is trying to do is get a leg up on Google, and purchasing Yahoo just won't do that.
Microsoft is better off buying something smaller, perhaps InterActiveCorp (IAC), owners of Ask.com and Excite, Evite, and Match.com, but even then it's only accomplishing the same thing. Whatever base they draw from, be it Yahoo, IAC, or MSN itself, they're going to have to do some radical building of new technology to go anywhere.
They are going to have to invest in actual development firm(s), and buy some up-and-coming companies like 37signals to get some real innovation. However, Google has already been doing this, so MS is getting sloppy seconds, and when you add that to the fact that Microsoft is horrible at the this concept (it's more typical that MS buys a company, takes its most salable product and integrates it into the MS product, then shelves the rest of the company and fires the staff).
ASP.NET is going to need some serious help gaining AJAX support if it wants to be a contender (or is this Silverlight's aspiration? *shudder*... Silverlight should contend with Flash. None of the big web2.0 apps use Flash). This absolutely must be key to their web services plan if they want to stay a "leader" in the PL field. Remember when Hotmail went offline because they couldn't successfully port it from BSD to Windows? They still managed to do it eventually (or does it just run though a proxy?)... porting languages is MUCH harder.
We're either on the same page, arguing the same thing, or you're missing some basic priciples of PKI. Salted encryption is needed so a man-in-the-middle attack can't replicate the all-clear signal.
I recommend reviewing the system of public key infrasctructure (PKI), which ensures the encrypting technology never sees the client system, and thanks to fingerprinting, you can't create a fake validation server with a new key for a man-in-the-middle attack. Everything you present as a hole is a rather basic tenet of PKI.
1. A man-in-the-middle attack is not possible within PKI because the private key is never exposed, and since its fingerprint is already known by the software, you cannot introduce a new private key pretending to be the legit one. Compromise the network all you like, you can't forge the encrypted transaction without breaking PGP. (Without the timestamp and salt, you don't need to break the encryption... just send the same traffic from your man-in-the-middle server that you captured from the first legitimate transaction. With that timestamp and salt, your copied traffic doesn't fit, and thus the attack fails.)
2. If by "entered by the user," you mean downloading a key file from the server after a financial transaction, yes. The mass-produced disks would indeed be identical. The unique bits come from the initial online registration process.
The client messages likely don't even need encryption (if they do, they would use the public key to encrypt something only the upstream server's private key can read). There is no user-created key in the equation, and there is no place for a man-in-the-middle key either. The server messages are not encrypted, only signed. Nothing needs encryption here, it can all be transparent. Since you can't forge the signature, there's nothing to encrypt beyond it.
The all-clear message must be algorithmically related to the client message and the algorithm must be contained in the client -- otherwise the software couldn't recognize it
The all-clear message merely contains the string of randomly generated characters (the "salt") and the time-stamp (both presented by the client system) plus the words "all clear," all without encryption. The security comes from the cryptographic signature, which ensures the validity of the above statement, and repeating the salt and timestamp ensures it was legitimately created in response to the client's query (rather than merely copied from an earlier request). The "secret algorithm" you elude to is PKI itself, secured by the signature and nothing more. You cannot reproduce the signature without the private key, which you'd have to hack the upstream server to get. No way around that.
The network level of my model is secure. As I said earlier and you repeated yourself, the best way to break this DRM model would be to crack the program's startup binary so that it doesn't send requests and doesn't need to receive the all-clear message to start the game.
A global system that checks whether a license is being used by multiple computers at once is all you need. There's no point in adding encryption on top of it since you're still basically sending the product key from the back of the DVD case. Heck, let it run on five computers at once, it's doesn't matter. The weak point in the piracy scheme is that you have a very small number of distributors purchasing copies to feed a very large number of downloaders. Millions of copies will be downloaded but there will only be a handful of keys. Invalidate those keys and you make piracy much more difficult.
No, I'm talking about one key per end-user, not per distributor. Salted encryption is necessary to avoid man-in-the-middle attacks that capture the all-clear signal, which could be repeated even if you can't decrypt it (if just time-stamped, the clock could be altered).
No, this is not how Steam works... or at least, this is not now the similar product I used to work on functioned. Basically, it works by ensuring you never have any of the actual data that doesn't require computing; the data actually streams off the network. In this model, since it's impossible to have all of the data, no DRM is needed. This model also requires a big pipe to the internet since you're effectively running it off an internet-mounted hard drive.
My model does only a quick check online, about the same level of bandwidth as an email. Some companies use a model similar to what I've described and guise the license-tracking bit as a "check for updates." This is significant because it means you can play over a dial-up modem or cell phone, you can start it and pause it for later, and most importantly, maintaining the servers on the manufacturer's side is trivial since there's no massive pull for the data like Steam et al.
Also, I should point out that my model was half-baked, coming right off the top of my head. There are surely areas to improve it. It's merely an example of DRM that works at least as effectively as the current models, but there is no need for hidden data.
the last time a game shipped with mandatory internet activation at the start of every game, people complained...
I have no response to your first reason. It's completely valid. The question is merely how much of a corner-case people like soldiers in Iraq really represent and then doing a cost-benefit analysis... of course, such a study typically proves that the DRM is so ineffective that you're losing more money than you're saving, thus resulting in the argument that consumer-grade software should not contain DRM... Moving on...
you haven't verified that the disc in the drive is actually from your factory and not, say, a CD burner, or a CD drive emulation. So you haven't solved the piracy problem at all.
Sure I have. I'm merely assuming that product activation is actually where the sale is. I once worked for a game distribution company with a model just like Steam... the execs at Sony said they were one step away from giving Everquest away for free, since it required the online service (they didn't, but I'm sure they don't really care about policing install media since you'll still need an account). The point is that if the license were tied to an activation that costs money, there is no more worry about burned CDs and protection from that. All such a copy would do is make the actual (legit) license purchase EASIER for the potential customer ("pirate").
somebody will just remove the authentication code from the game
What authentication code? The license key file? It's merely a database entry on the server. If it gets abused, it gets removed. Or do you mean the verification code itself, which I've already flagged as the best place to attack this model?
It's a lot easier to implement when you can control the hardware, which is why the PS3 has unbroken DRM for 2+ years now, and why breaking the DRM on the Xbox 360 comes with a long list of serious caveats (eg, no xbox live ever again).
The coolest example of a hardware solution in a console system I know of was the Nintendo Game Cube, whose disks actually spin the opposite direction (IIRC).
Here's a sample DRM model using PKI off the top of my head: When a customer buys the software, the server sends a license key file. This file is keyed to that license and the product's serial number, and the customer should be able to back up that file so that it can be re-installed later (since every Windows user should re-install Windows from scratch every ~9-24 months anyway). When the software launches (and perhaps at certain major intervals in the software), it sends the license key (and a randomly generated "salt") to an SSL-encrypted server hosted by the manufacturer, which verifies the key and the fact that nobody else is using it at the time, then sends a PKI-signed "okay" message (with the date and salt for uniqueness) back to the software.
By moving the authentication to a trusted server, the hackability of DRM should be almost completely removed since you can't forge the signature (so the only way to hack this model is to break the launcher to bypass the lookup). The only downside is that internet access is needed when the program launches, which could conceivably be solved by launching the program at home and pausing it or suspending your laptop before bringing it to wherever you're going without internet connectivity.
That said, I would still never use software or media encumbered by this or other forms of DRM, and I feel nothing wrong with buying it (hopefully used) and then breaking it for my own use. Aside from Quake III for Linux, I don't think I've purchased (used or not) or even "stolen" any software since the 90s. I also debate the "stealing" connotation here as nothing is being taken, including potential payment, as "pirated" content cannot be assumed desirable enough to purchase. (Remember shareware?)
This model works only if the government owns it.
on
Houses With Tails
·
· Score: 1
We don't want to own the fiber, because then we have to pay the service crew to maintain it when it's hit by a fallen tree or flooded by a ruptured pipe (or even if we do want to pay for that, we get shafted by our lower priority for being such a minor player).
Realistically, this should be purchased on our behalf by the local city government. Perhaps the service should be provided at-cost to the individual, with a little extra padding for rainy days (sometimes literally).
More realistically, this is entirely stupid. There won't be any need for this "last mile" in a few years (the time it would take to implement the thing anyway), since high-powered wifi/wimax/etc solutions will be feasible by then. With that in mind, you're not owning something that has anything to do with where you live, you're merely owning a piece of virtual bandwidth somewhere. This further highlights the stupidity of the suggestion, as it's along the same lines as commoditizing fresh air (which has actually been proposed as a way of ensuring pollution is kept in check, see an Inconvenient Truth).
Rather than thinking of interesting ways to re-privatize the ISP industry modeled after real estate, I'd prefer to see interesting ways of nationalizing the ISP industry modeled after the interstate highway system or the post office; the internet is a public service for the people, regulated for safety and throughput in manners that corporations would never do (do you really think it's worth UPS's while to have offices in towns in the middle of nowhere? of course not; it's nowhere near profitable, which is why the USPS, the Highway system, and Amtrak will never even resemble profitable enterprises).
What do they plan to tax? Their revenues? Is it just that whenever there's money anywhere the IRS thinks uncle sam should get a share of it? Are they claiming that Firefox is some kind of tax shelter? I don't think that's the case. ..
I could be convinced there's something fishy out there; if you assume a top-tier US-based developer costs $133k/yr (salary.com reports level 5/5 software engineers in Silicon Valley get this, so this is a high-ball), $75 million would buy you 561 of the world's best developers. Most of the Mozilla Foundation's employees moved up to the Mozilla Corporation when that was founded. The Wikipedia page says that the Mozilla Foundation has FOUR employees.
How much is reasonable for operational and marketing costs? If we assume $15 million (a lot?), that's still $60 million left over, which would finance 449 of the most expensive software engineers in the world. Better spending would easily push the number of quality engineers past a thousand, with which I'd expect a LOT more development (vaporware counts here!) than what we've seen. And that's ignoring the fact that large amounts of code come from external corporations (and individuals) interested in fixing the calendar (etc.) or adding functionality through patches, add-ons, plugins and forks.
They aren't necessarily looking for more money. They are simply wondering where all that money went. When there's a black hole like this, it often means there is a larger problem, and that larger problem is often justly labeled "tax evasion." Whether or not Mozilla is guilty of this remains to be seen.
It's an official Scrabble word (TWL '06, the current authority), though you have to make sure that you're playing with a version of the list that includes the longer words. Humorously, "devertebrated" is not an official Scrabble word at all. (The TWL is the union of five popular collegiate dictionaries, and it very purposefully does not include the unabridged Oxford English Dictionary.)
Slashdot Mirror
First, we were discussing "modern operating systems" which I took to mean your typical desktop systems from this millennium rather than things like crays and even clusters.
Second, I'm under the impression supercomputers do not multi-task, so there would never be anything to swap in the first place (or if there were, it would be hand-written by the specific app.
Linux kernel maintainer Andrew Morton sets his swappiness to 100 (page as much physical memory as you can, the opposite of this Ask-Slashdot's desires), which he justified in an interview (see above link) by saying:
My point is that decreasing the tendency of the kernel to swap stuff out is wrong. You really don't want hundreds of megabytes of BloatyApp's untouched memory floating about in the machine. Get it out on the disk, use the memory for something useful.
Of course, there's another view, also presented at the above kerneltrap article: If you swap everything, you'll have a very long wait when returning to something you haven't touched in a while.
If you have limited resources, milk the resources you have plenty of; workstations should have high swappiness while laptops, who suffer in disk speed, disk capacity, and power, are probably better suited with lower swappiness. Don't go crazy, though ... swappiness = 0 is the same as running swapoff -a and will crash your programs when they need more memory than is available (as the kernel isn't written for a system without swap).
I recall back in 2002 or so, a friend of mine maxed out his Windows XP system with 2gb of memory. Windows absolutely refused to turn off paging (swap), forcing him to whatever the minimum size was. The solution? He created a RAMdisk and put the paging file there.
On Linux (and other modern systems, perhaps now including Windows), you can turn off swap. However, the Linux kernel's memory management isn't so great at the situation you hit when you need more memory than you have, but you can't swap. Usually, the memory hog crashes as a result (thankfully, Firefox now has session restore). I might be slightly out of date on this one.
A well-tweaked system still has swap (in nontrivial amounts), but rarely uses it. Trust me, you can afford losing the few gigabytes from your filesystem. Again in Linux, /proc/sys/vm/swappiness can be tweaked to a percentage reflecting how likely the system is to swap memory. Just lower it. (Though note the cons to this presented at the kerneltrap article above.) My workstation currently has an uptime of 14 days, a swappiness of 60, and 42/1427 megs of swap in use as opposed to the 1932/2026 megs of physical memory in use at the moment.
This is summarized for Windows and Linux on Paging at Wikipedia.
This means it doesn't need some "Homeland Security" back-door, it doesn't need to turn a blind eye to corporate root-kits and other DRM-enforcers, and it can be harsh on corporate spyware.
You'll find crap in any of the vendors. Hell, the whole industry is a con; this is one of the few items that actually SHOULD be bundled into the operating system (IMHO), and the fact that Windows Update doesn't have it built-in is a comedic result of the anti-trust issues Microsoft has earned from its abuse of that concept in other areas.
Yes, Kaspersky's defaults on those two areas are stupid. Fortunately for my company, I can change that on the server so that new installs never need to worry about it. The fact that AdminKit uses MMC rather than its own UI is also host to a ton of issues, and I'm still waiting for a web-based administration option (like with Trend Micro, but hopefully without requiring ActiveX).
I never did understand hosting mail on a Windows server... Exchange may be nice, but I don't intend to ever find out.
NOD32, BitDefender, and Avira all look just as viable as Kaspersky. I'm sure each one has its own baggage. Good luck.
Ignoring the assumption that all viruses come from Russia, wouldn't that make it more likely that the virus developers would make sure their viruses can evade detection under it?
First, that assumption was a joke. My humblest apologies if that offended anybody. Second, it's a common practice to not "pee in your own pool," which is to say that viruses are written for a target, which should not include the writers' personal systems (since they know better). The assumption that I am making is that this target is more likely to be one or more of the top three anti-virus solutions (McAfee, Symantec, Trend Micro).
Furthermore, the areas Kaspersky is developed and popular in could be viewed as having a larger number of people who may have had sophomoric experience writing viruses but who have since reformed. That means that their personal background might make them quite qualified to choose an anti-virus solution. It also means that Kaspersky has a better pool of applicants when hiring developers than the competition.
I can also attest to the results of Soviet education helping here; my company's offshore developers in ex-Soviet regions are very well prepared for software development. I have friends and I've had (on-shore) co-workers who also fit this bill.
This article (at Mongabay, not Science) starts out strong, saying "accessible and unpolluted freshwater is a necessity for every nation's stability and well-being." Unfortunately, that first sentence was the last reference in the article to the issue of pollution or non-salt contamination.
What we really need is the ability to farm directly in the ocean without producing inedible food. The article's referenced halophytes (plants that can grow in salt water) are just one piece of the issue, as the ocean is also filled with other contaminants (mercury, industrial waste, and so very much more). We can probably do some farming with net-like filters around enclosed areas (similar to the way most fish farming works). Wikipedia calls this "open cage aquaculture." However, these filters can only get so much, and once you get complex enough to need a treatment facility, you've defeated the purpose of farming in the ocean (unless you treat the whole ocean...).
The referenced Science Magazine article gets published tomorrow, but you can see related documents by searching for the authors (Rozema and Flowers) and salination. Perhaps the actual article will discuss this issue...
We use Kaspersky for Windows systems at work (and ClamAV on Linux for mail, though that might change to Kaspersky as I believe we have a license for it). When employees ask if they can use our licenses for their personal machines, I point them at Avira AntiVir because it's about as good and it's FREE FOR PERSONAL USE (although the free version has less spyware detection). It blows AVG out of the water.
Here are some useful links from my research, which included the above site:
From the Wikipedia links and other research that I didn't bother to note to my colleagues (who were also doing this research), I determined that Kaspersky's software was among the most efficient and CPU-friendly. It's only downside was a less-than-optimal user interface, especially on the administrative side for the corporate product. We didn't mind its UI flaws in the free trial period, so we purchased it. We're still happy with it several months later.
The main arguments for our switching from Trend Micro were that it was slow, had poor performance, missed several viruses, we wanted to boycott it, and we were tied to a very old version (since it out-performs the newer ones in reviews). Arguments for switching to Kaspersky included: it doesn't feel bloated (remember when that was the norm?), great performance, well received across the board in reviews, dirt cheap (new licenses are 70% the current renewal cost of Trend Micro, which is an ever-growing target), we liked the UI that prevented reviewers from giving it a perfect score, and it's the de-facto number one scanner in Russia and surrounding area (you know, where all the viruses come from?). Kaspersky is also growing rapidly in deployments; you can now get computers installed with it.
A certificate-based login (which you can play with at www.cacert.org) would solve this problem. When you initially set it up with your bank, they should require gobs of information proving your identity (full card number, CCV, address, social security number, and last ATM transaction data should suffice), and then they'll let you generate a key for your browser. This easily qualifies as "something you have" for two-factor authentication without needing anything silly like a USB key that would cost the bank money on a per-key basis in time and resources. (Footnote: This isn't as well documented as it should be; your best bet is to play with cacert.org's free implementation. There's tidbits of it in Wikipedia's TLS article, and cacert's wiki has a decent Client Certs page that says a little more.)
After that, you'll need that key plus the tools already employed. Most banks these days already have interesting ways to prove their own identity to you (they supply you with an image and some secret text you agreed upon earlier), then they have some clever input mechanism that tries to bypass keyloggers and javascript hacks.
Also recall that banks are VERY good about locking your account; a properly protected four-digit number is actually secure enough if you're only allowed two failed logins per day (regardless of source) since the code would take up to 5000 days (13+ years) to crack, and I'm sure there are further safeguards for that kind of case.
To banking software firms: I would immediately switch* to an online bank that performs this configuration. So would others. Don't forget: people like me are consulted regularly by family and social networks for advice about this very topic. (* Assuming the bank is FDIC/NCUA-insured, otherwise well-received and regarded, and fully pays for a few ATM usage fees each month).
Good call on that. It took me a while to figure that one out when Debian added PAM to the mix. Always test!
First and foremost, like all the other posts here, I'll tell you that you should not pursue legal advice from blogs like Slashdot. Even if people here claim to be lawyers, they likely are not, and even if they actually are, you are NOT being given legal advice (in the best case, you're getting their hasty first impressions).
Second: Such ownership rights are usually solidified upon employment by means of signing some kind of contract that agrees on who will own what. Without that, there may still be precedents for one way or another, but there may be enough ambiguity to work out a compromise that is favorable to all involved parties.
Offer to give them the copyright in exchange for an "non-exclusive infinite license" (that is not a legal term), effectively entitling you to use it outside the courtroom as if you had copyright, so you could sell licenses, GPL it, etc. If that's too strong (or more than you want), ask for a GPL, AGPL, or LGPL (the first two preserve the profitability of the copyright, since closed-source software is considerably more salable). They still get to use it however they like as the copyright holders, and your Free Software use probably won't get in their way anyway. If you think they'd be game for it, start the haggling in the other direction -- offer them the infinite license. If they take that, you'll probably have to include some kind of clause covering what happens if legal action is needed to protect it, as the copyright holder is the only party that can act on that (which is why the FSF requires copyright attribution for all GNU projects).
If you want FREE legal advice, you may be able to ask the Software Freedom Law Center (SFLC) for it at http://www.softwarefreedom.org/
Fail2ban actually bans the offending IP after several failed authentications within a small window of time, and the ban is only for a small window of time ... the purpose is not defensive for security, but rather for bandwidth preservation; it's okay for somebody to try a few pokes here and there, just not a flurry of them.
The only bit that BruteForceBlocker has that fail2ban does not is that of the reporting and checking mechanism, which appears to be a recent addition. I don't see any indication that the blocklist is a well-groomed and up-to-date list, which is huge problem, as most of the IPs used by botnets are dynamic, and any one of them could be cleaned or re-allocated for legitimate use in the future. This lends itself to the same issues as your typical DNSBLs, which is why I proposed such a thing over a more generic blacklist.
Given the issue with maintenance, I'd stay clear of that feature. It might be useful for sharing temporary blocklists between your own servers, but you must be sure to rotate them periodically so that they do not grow stale.
That brings me to the next issue - efficiency. I don't know too much about the inner workings of pf or iptables, but if you have a poorly implemented filter hosting a lookup table with tens of thousands of IPs to check against, you're going to slow your system's entire internet traffic pipe considerably.
Rather, this appears to be suspended animation, which frankly I find more interesting anyway. While you're suspended, you're clinically "dead," which is a state we can already induce with various toxins (supposedly, with intense meditation, yogis can do this as well).
SSH keys ensure that you're virtually immune to attacks, since the attack now MUST be brute-force (or break the RSA/DSA algorithms or compromise the server itself rather than an account), and must crack a "password" of over 150 base64 characters representing the 1024 bits of entropy in the key; a completely random printable password of 20 characters has 130 bits of entropy and an 8-word Diceware passphrase has only 120; you're not brute-forcing that.
Preventing root from accessing remotely is just smart (your logs can show who really logged in, your sudo logs show who needed root-level access and when, and you can auto-ban root logins immediately rather than after a set number of failed authentications).
All we're missing is the extension to #3 to handle distributed attack failures (as proposed by the parent post); with the proper protections, this is a bandwidth issue rather than a security issue (unless you're worried about DDoS, but we're talking about low-intensity attacks here).
For those of you stuck permitting passwords, you'll want something like John the Ripper to brute-force users' insecure passwords before the enemies do. This way you can disable their accounts when you find that they are vulnerable and force them to change their password to something more secure.
I use Fail2ban on all of my iptables-based SSH servers, as it eliminates the possibility of brute-force attacks from single IPs (fail2ban will ban any IP with five failed ssh logins in a ten minute period. The ban vanishes after ten minutes).
However, this new botnet attack distributes the attack over the IP-space and time. That bypasses fail2ban!
The only solution I can see to this would be to take an approach similar to the centralized spam-fighting solutions; a DNSBL specialized for brute-force botnets. You run something that monitors your logs for failed logins (with a large scope for time, say ten failed attempts in a month). When an IP triggers it, you block that IP for a month and report it to the DNSBL. The DNSBL operates like Spamcop, trying to verify the nature of the IP (and trying to address the issue), then adding it to the blocklist. Anything listed on a DNSBL gets permanently blocked after one failed authentication, and if your internal list grows too big, any positive IP gets blocked before the login attempt.
Yeah, looks like I missed that one. You and two ACs pointed that out ... oops. I'm not really exposed to MS server stuff outside the Active Directory realm these days, and my social networking seems to have stagnated in the MS world; I used to have a number of friends who were in the ASP.NET camp, but most of them converted to other things (rails, j2ee, cakePHP, and non-web development with C#) and I lost track of some of them, too.
Yahoo represents the "old web" that Google is beating the pants off of. I wouldn't be surprised if Microsoft/MSN's own resources are as good or better. What Microsoft is trying to do is get a leg up on Google, and purchasing Yahoo just won't do that.
Microsoft is better off buying something smaller, perhaps InterActiveCorp (IAC), owners of Ask.com and Excite, Evite, and Match.com, but even then it's only accomplishing the same thing. Whatever base they draw from, be it Yahoo, IAC, or MSN itself, they're going to have to do some radical building of new technology to go anywhere.
They are going to have to invest in actual development firm(s), and buy some up-and-coming companies like 37signals to get some real innovation. However, Google has already been doing this, so MS is getting sloppy seconds, and when you add that to the fact that Microsoft is horrible at the this concept (it's more typical that MS buys a company, takes its most salable product and integrates it into the MS product, then shelves the rest of the company and fires the staff).
ASP.NET is going to need some serious help gaining AJAX support if it wants to be a contender (or is this Silverlight's aspiration? *shudder* ... Silverlight should contend with Flash. None of the big web2.0 apps use Flash). This absolutely must be key to their web services plan if they want to stay a "leader" in the PL field. Remember when Hotmail went offline because they couldn't successfully port it from BSD to Windows? They still managed to do it eventually (or does it just run though a proxy?) ... porting languages is MUCH harder.
We're either on the same page, arguing the same thing, or you're missing some basic priciples of PKI. Salted encryption is needed so a man-in-the-middle attack can't replicate the all-clear signal.
I recommend reviewing the system of public key infrasctructure (PKI), which ensures the encrypting technology never sees the client system, and thanks to fingerprinting, you can't create a fake validation server with a new key for a man-in-the-middle attack. Everything you present as a hole is a rather basic tenet of PKI.
1. A man-in-the-middle attack is not possible within PKI because the private key is never exposed, and since its fingerprint is already known by the software, you cannot introduce a new private key pretending to be the legit one. Compromise the network all you like, you can't forge the encrypted transaction without breaking PGP. (Without the timestamp and salt, you don't need to break the encryption ... just send the same traffic from your man-in-the-middle server that you captured from the first legitimate transaction. With that timestamp and salt, your copied traffic doesn't fit, and thus the attack fails.)
2. If by "entered by the user," you mean downloading a key file from the server after a financial transaction, yes. The mass-produced disks would indeed be identical. The unique bits come from the initial online registration process.
The client messages likely don't even need encryption (if they do, they would use the public key to encrypt something only the upstream server's private key can read). There is no user-created key in the equation, and there is no place for a man-in-the-middle key either. The server messages are not encrypted, only signed. Nothing needs encryption here, it can all be transparent. Since you can't forge the signature, there's nothing to encrypt beyond it.
The all-clear message merely contains the string of randomly generated characters (the "salt") and the time-stamp (both presented by the client system) plus the words "all clear," all without encryption. The security comes from the cryptographic signature, which ensures the validity of the above statement, and repeating the salt and timestamp ensures it was legitimately created in response to the client's query (rather than merely copied from an earlier request). The "secret algorithm" you elude to is PKI itself, secured by the signature and nothing more. You cannot reproduce the signature without the private key, which you'd have to hack the upstream server to get. No way around that.
The network level of my model is secure. As I said earlier and you repeated yourself, the best way to break this DRM model would be to crack the program's startup binary so that it doesn't send requests and doesn't need to receive the all-clear message to start the game.
No, I'm talking about one key per end-user, not per distributor. Salted encryption is necessary to avoid man-in-the-middle attacks that capture the all-clear signal, which could be repeated even if you can't decrypt it (if just time-stamped, the clock could be altered).
No, this is not how Steam works ... or at least, this is not now the similar product I used to work on functioned. Basically, it works by ensuring you never have any of the actual data that doesn't require computing; the data actually streams off the network. In this model, since it's impossible to have all of the data, no DRM is needed. This model also requires a big pipe to the internet since you're effectively running it off an internet-mounted hard drive.
My model does only a quick check online, about the same level of bandwidth as an email. Some companies use a model similar to what I've described and guise the license-tracking bit as a "check for updates." This is significant because it means you can play over a dial-up modem or cell phone, you can start it and pause it for later, and most importantly, maintaining the servers on the manufacturer's side is trivial since there's no massive pull for the data like Steam et al.
Also, I should point out that my model was half-baked, coming right off the top of my head. There are surely areas to improve it. It's merely an example of DRM that works at least as effectively as the current models, but there is no need for hidden data.
I have no response to your first reason. It's completely valid. The question is merely how much of a corner-case people like soldiers in Iraq really represent and then doing a cost-benefit analysis ... of course, such a study typically proves that the DRM is so ineffective that you're losing more money than you're saving, thus resulting in the argument that consumer-grade software should not contain DRM ... Moving on...
Sure I have. I'm merely assuming that product activation is actually where the sale is. I once worked for a game distribution company with a model just like Steam ... the execs at Sony said they were one step away from giving Everquest away for free, since it required the online service (they didn't, but I'm sure they don't really care about policing install media since you'll still need an account). The point is that if the license were tied to an activation that costs money, there is no more worry about burned CDs and protection from that. All such a copy would do is make the actual (legit) license purchase EASIER for the potential customer ("pirate").
What authentication code? The license key file? It's merely a database entry on the server. If it gets abused, it gets removed. Or do you mean the verification code itself, which I've already flagged as the best place to attack this model?
The coolest example of a hardware solution in a console system I know of was the Nintendo Game Cube, whose disks actually spin the opposite direction (IIRC).
Here's a sample DRM model using PKI off the top of my head: When a customer buys the software, the server sends a license key file. This file is keyed to that license and the product's serial number, and the customer should be able to back up that file so that it can be re-installed later (since every Windows user should re-install Windows from scratch every ~9-24 months anyway). When the software launches (and perhaps at certain major intervals in the software), it sends the license key (and a randomly generated "salt") to an SSL-encrypted server hosted by the manufacturer, which verifies the key and the fact that nobody else is using it at the time, then sends a PKI-signed "okay" message (with the date and salt for uniqueness) back to the software.
By moving the authentication to a trusted server, the hackability of DRM should be almost completely removed since you can't forge the signature (so the only way to hack this model is to break the launcher to bypass the lookup). The only downside is that internet access is needed when the program launches, which could conceivably be solved by launching the program at home and pausing it or suspending your laptop before bringing it to wherever you're going without internet connectivity.
That said, I would still never use software or media encumbered by this or other forms of DRM, and I feel nothing wrong with buying it (hopefully used) and then breaking it for my own use. Aside from Quake III for Linux, I don't think I've purchased (used or not) or even "stolen" any software since the 90s. I also debate the "stealing" connotation here as nothing is being taken, including potential payment, as "pirated" content cannot be assumed desirable enough to purchase. (Remember shareware?)
We don't want to own the fiber, because then we have to pay the service crew to maintain it when it's hit by a fallen tree or flooded by a ruptured pipe (or even if we do want to pay for that, we get shafted by our lower priority for being such a minor player).
Realistically, this should be purchased on our behalf by the local city government. Perhaps the service should be provided at-cost to the individual, with a little extra padding for rainy days (sometimes literally).
More realistically, this is entirely stupid. There won't be any need for this "last mile" in a few years (the time it would take to implement the thing anyway), since high-powered wifi/wimax/etc solutions will be feasible by then. With that in mind, you're not owning something that has anything to do with where you live, you're merely owning a piece of virtual bandwidth somewhere. This further highlights the stupidity of the suggestion, as it's along the same lines as commoditizing fresh air (which has actually been proposed as a way of ensuring pollution is kept in check, see an Inconvenient Truth).
Rather than thinking of interesting ways to re-privatize the ISP industry modeled after real estate, I'd prefer to see interesting ways of nationalizing the ISP industry modeled after the interstate highway system or the post office; the internet is a public service for the people, regulated for safety and throughput in manners that corporations would never do (do you really think it's worth UPS's while to have offices in towns in the middle of nowhere? of course not; it's nowhere near profitable, which is why the USPS, the Highway system, and Amtrak will never even resemble profitable enterprises).
What do they plan to tax? Their revenues? Is it just that whenever there's money anywhere the IRS thinks uncle sam should get a share of it? Are they claiming that Firefox is some kind of tax shelter? I don't think that's the case. . .
I could be convinced there's something fishy out there; if you assume a top-tier US-based developer costs $133k/yr (salary.com reports level 5/5 software engineers in Silicon Valley get this, so this is a high-ball), $75 million would buy you 561 of the world's best developers. Most of the Mozilla Foundation's employees moved up to the Mozilla Corporation when that was founded. The Wikipedia page says that the Mozilla Foundation has FOUR employees.
How much is reasonable for operational and marketing costs? If we assume $15 million (a lot?), that's still $60 million left over, which would finance 449 of the most expensive software engineers in the world. Better spending would easily push the number of quality engineers past a thousand, with which I'd expect a LOT more development (vaporware counts here!) than what we've seen. And that's ignoring the fact that large amounts of code come from external corporations (and individuals) interested in fixing the calendar (etc.) or adding functionality through patches, add-ons, plugins and forks.
They aren't necessarily looking for more money. They are simply wondering where all that money went. When there's a black hole like this, it often means there is a larger problem, and that larger problem is often justly labeled "tax evasion." Whether or not Mozilla is guilty of this remains to be seen.
It's an official Scrabble word (TWL '06, the current authority), though you have to make sure that you're playing with a version of the list that includes the longer words. Humorously, "devertebrated" is not an official Scrabble word at all. (The TWL is the union of five popular collegiate dictionaries, and it very purposefully does not include the unabridged Oxford English Dictionary.)