The most significant events I see which correlate with that graph are Memorial Day weekend and the start of summer. When I report spam to spamcop, it's usually in 15-20 message batches. Deleting the messages takes less than 2 minutes. Forwarding all the spam to spamcop, then clicking through all the pages for reporting each piece takes 30+ minutes.
I think what most of what you're seeing is people having more attractive things to do than report spam.
Being that I don't know the competency of every coder that writes every line of code of all the software that I use, a little sandboxing is nice every now and then. For example, protected memory by an OS is a good thing(tm).
Agreed, anything that depends on humans being perfect is flawed from the start. Luckily, code auditing is only part of OpenBSD's overall approach to security.
On the topic of protected memory by the OS, the OpenBSD team was right on top of W^X, and hounded Sun to get specs on their UltraSparc III processor to that end. Sun didn't co-operate, so they chose AMD64 as their platform of choice as it's also 64 bit and has W^X protection (including specs of how to use it, and is faster and cheaper than Sun gear!)
Since then, they've also come up with a way to get i386's memory protection (basically: don't execute anything above this address) to do something useful. The OpenBSD linker re-arranges code and data, so the code comes first followed by the data. That way, the execution boundary can be set at the end of the code. Oppose how other operating systems handle i386 - code and data are mixed together, so the i386 memory protection is useless.
Other niceties are propolice, a stack protection tool being enabled by default. Shared libraries being shuffled by the linker so an attacker that depends on a specific memory address for a library, or a chain of libraries will have a much harder time. Privilege separation is pervasive throughout the OS (both dropping to a non-root user to perform tasks which don't require root and chrooting - eg, there is a _tcpdump user for processing packets once the steps requiring root have been done)
Oh, and I applaud OpenBSD's continuous code auditing, but when is going to make any kind of presence anywhere? I've never seen or heard of anyone running OpenBSD. It seems as though there are other things besides code review and security that gets products in use.
I feel this pain, too. For me, the problem has been with hardware support for SCSI/RAID controllers. That was some time ago, though and that particular item looks like it's mostly addressed provided careful selection of components. In any case, I still am able to benefit by using OpenBSD to do firewalling and DNS.
However, most of the techniques I mentioned are relatively low-hanging fruit other operating systems could easily pick were they interested. After all, the hard part of developing the techniques and getting them working has already been done. Now there is a working example to study, and most of the code is BSD licensed.
Understood. I was speaking of practicality. It would be illegal for them to randomly snoop around, grabbing anything that looks interesting, too, if all they were supposed to be doing was installing patches and doing virus scans.
Colleges should not have administative control over students' PC's. In the workplace, it's a different issue entirely, since the the machine is generally company property and used specifically for work. In the case of a student PC, it is a personal machine, and likely to have highly personal data.
Giving a college employee (who is likely a student) access to run any program with administrator rights is ripe for abuse. Even if this is limited to running a batch file daily (or weekly or...) it would be trivial to add functionality to, for instance, copy all.gif files to look for an off color photo of any of the female students... or delete a research paper, install a keylogger, (re)enable a webcam's image capturing to see what you were missing while the owner thought it was off etc.
Of course, you also mentioned the problem of the machine giving out all these patches being compromised. Even if your college were lucky enough to find someone honest enough to not do anything intentionally evil, compromise of that one machine would provide the attacker access to run anything as administrator on all connected systems.
This is reminiscent of landlord/tenant laws. The landlord is required to give notice before entering someone's living space. And similar to the difference between department stores monitoring their dressing rooms for shoplifting vs. your landlord putting a camera into your bedroom and bathroom "to make sure you aren't using drugs / damaging anything/etc"
It may be legal for the college to do this, but certainly isn't something it should be doing.
Anyway, I'd be configuring VMWare run the university-accessible copy of Windows and only use that for NAT. Anything you send over their network cleartext is fair game, anyway.
Although there is a big usability difference, there is not philisophical difference, as the summary seems to imply.
There is a philosophical difference, but it's "Part-time Linux User vs. Full-time Linux User who runs a Windows program" (contrast "stick it to Microsoft vs. give money to Microsoft" which you appear to be getting at).
Also, over the long-term, being a Linux user who runs a Windows program does tend toward sticking it to Microsoft. Spending full-time in the Linux user environment with one nagging dependency is a clearer path to ultimate independence from Windows-based software; As a full-time Linux user, the itch is to get rid of that Windows dependency. As a dual boot user, the tendency is to stay in the currently booted environment until you want something in the other environment enough to close everything and reboot.
Not to mention the practical benefits of spending as little time as possible in a breeding ground for viruses and other malware... or the network effect of the existence of more full-time Linux users, (some of whom happen to run a program under win4lin).:-)
And exactly how is giving NASA my credit card number going to prevent another 9/11?
It won't. What really needs to be done to prevent another 9/11 from occuring is to remove the 11th of September from our calenders, and tack on a September 31st to offset the removal of the 11th. Much like the what is done with the 13th floor on many taller buildings.
I had the opportunity to attend an excellent presentation about this subject at BSDCan. The presentation was about Ile Sans Fil, a wireless community being developed in Montreal, Canada. They've got a website at http://www.ilesansfil.org/ with user documentation and a Wiki with all the technical details about getting it off the ground. (It defaults to French, but there's a switch to English link for those so inclined)
Basically, what they are doing is getting coffee shops to pay a small fee to host the access points (running a custom Linux configuration), networking those, and offering both the internet connection on the coffee house's dime and building out their own BBS-like intranet service.
Maybe the idea would be harder to get off the ground in other parts of the world, but if you can swing it, I think internet access is a big draw for people who otherwise may not bother.
The in-beta NetBSD 2.0 will support SMP, it's probably a lot like OpenBSD since OpenBSD was a fork from NetBSD.
I use both OpenBSD and NetBSD. In that they're both BSD's, they're put together in a similar way, but it has been a long time since the fork.
For instance, OpenBSD releases on a 6 month schedule, usually keeps source-based upgrades working (except in the case of binary executable format changes), and is really tilted toward improving security.
NetBSD, while also a nice OS (the first free unix w/ USB support, and had wireless going seamlessly - both release quality and stable long before LInux) it doesn't feel the same as an admin. Source updates aren't supported, you don't get everything chrooted and locked down by default, and new releases aren't tied to any schedule.
If you want SMP on BSD, FreeBSD has been there for years, and also sticks to a regular release schedule. Since it has a large community surrounding it, it also has nice things like Binary Updates
At 600 barrels crude/day/ea for these plants, it would take 16 and 2/3rd's of these to feed a 10,000 bcd/refinery.
Of course, if they can scale this and apply it to other types of waste as mentioned (so they don't run out of turkeys!) it could become a valuable alternative crude oil source... But probably not poised to replace petroleum imports in the near future.
In any case, getting a useful product out of what started as 200 tons / day of thrown out turkey parts is useful on its own, and could definitely tilt the scales toward cost-effectiveness.
Over here is an article (from May 2003) that suggests the pilot facility was $20 million:
When it is commissioned later this month, the $20 million facility in Carthage, Missouri,funded in part by a $5 million grant from the US Environmental Protection Agency,will process 200 tons per day of fats, bones, feathers, grease and oils.
I have no idea how that translates to fiscal feasibility, but Con-Agra, the other party to the joint-venture is as an old, well-established agricultural company (i.e., not a startup whose primary business is selling shares) And, they actually have generated saleable oil.
On the other hand, they're touting this more as a waste management technique more than an energy source. The pilot plant is producing 100-200 barrels/day (with a 600 theoretical limit). A quick google search shows refineries processing 10,000 - 437,000 barrels crude/day
So, it would take 100 of these plants to feed the smallest of those refineries.
No, I'm not sure. Don't mistake me for an expert on this set of vulnerabilities. I was going by what was said in the link and on the OpenBSD misc@ mailing list.
According to some messages on the list, Cisco was one of the worst affected by the recently announced set of TCP vulnerabilities, and OpenBSD had only minimal exposure in the first place.
It strikes me that this may be PR ploy on Cisco's part to cover up for their past mistakes by appearing to rush to the rescue with a patent pending solution. They'll even graciously let others use them in exchange for cross-licensing. After all, if it's pending a patent, those Cisco guys must be really on the ball...right?;)
Personally, I trust the OpenBSD project a great deal more than Cisco when it comes to security. I mean, OpenBSD wasn't even vulnerable to the no-workaround backdoor password issue!
Luckily in that case, locking a user account had a considerable amount of prior art.
So you can have more secure communications, but only if you pay Cisco.
Actually, according to the "full details" link, you can have more secure communications, but only if you pay attention to OpenBSD's recommendations (and ignore Cisco's patent-encumbered implementation which isn't as good).
This is the second time in six months OpenBSD has seriously one-upped Cisco and its patents.:-) They even wrote a song about the first!
Looks like an excellent release!
on
OpenBSD 3.5 Released
·
· Score: 4, Informative
I picked up OpenBSD with version 2.3 and started using it seriously with version 2.5. During that time, it has gone from being an audited and secure (but otherwise fairly plain) OS to a compelling system with a wide range of complementary features.
The ones that stand out for me are -
Chrooting and dropping privileges for BIND by default (kept me feeling fairly safe through a few vulnerabilities, and without the extra work of maintaining my own bind built for chroot)
Picking up ssh and releasing a good, free version
Coming up with the nicest firewall I've used, taking it from nothing to ready for release within 6 months (That still amazes me!)
spamd - After breaking 400 spam messages a day directed at my inbox, wiring Spamhaus SBL into the firewall and tarpitting a good portion of the traffic is a nice bonus. Noticing a week after setting that up that OpenBSD 3.5 has graylisting is a nice surprise.
Propolice stack protection built into the OS and integrated for the long haul
Now with CARP, I can feel comfortable getting all this in any environment - I think failover support really opens up a lot of possibilities for the future of OpenBSD.
All in all, OpenBSD has all the attributes I like in an OS -
regular 6 month releases (production quality doesn't have to mean stale),
cohesiveness (no waiting for glibc to catch up to a new kernel feature, or vice-versa),
a real commitment to free software (as demonstrated with OpenSSH, pf, and now CARP)
really delivering - as opposed to various Linux security projects that I've seen integrated with mainstream distros, then apparently forgotten about or relegated to a special option marked with a warning label, OpenBSD is a real tested system.
As a system, it can progress toward its goals through every aspect of the system (eg., the pervasive privilege separation), rather than a patchset to a mainstream distro, which has inherent lag time and may be working at cross-purposes to that distro or the numerous projects that make up the distro it's trying to secure. I've seen a few patchsets come and go over the years, too, while OpenBSD keeps adding to the foundation they've built.
Thanks, OpenBSD team, for all the great releases... (and all the fish;)
Now I'm off to explore my new OpenBSD 3.5 system, where make build just finished.:-)
The only Windows I use is Windows XP Professional as a unix admin in a corporation, so some items may be notably absent. My entire Windows list is software that can be used royalty-free for commercial use )with an obvious emphasis on Free Software).
For example, I use XFree86 shipped with Cygwin for my X server, WinSCP for secure file transfer, Spybot S&D (and not AdAware, which is another excellent product, but would require a licensing fee be paid).
I don't use Winzip at all, since that functionality is built into the explorer interface in Windows XP Professional (don't know about the others), and is also available through Cygwin.
On the occasion I'm visiting a friend who runs Windows on a personal desktop, I also recommend Zinf, the audio player, since it's free software and just plays the music without any corporate spyware tie-ins, eg., contacting a server based on mp3 header fields as WMP and Winamp have started doing.
I think what you're missing is that the companies in the San Jose/San Francisco area essentially inflicted it upon themselves by basing their operations to that region.
During the.com bubble, I worked for a company headquartered in San Jose, and the business climate there was downright hostile. Difficult to rent rooms, get flights, office space (for startups, this usually involved huge rents + giving up part of the company)
Of course, this also extended itself to labor. Since the cost of living had been driven up so high by all of those companies basing their operations there, and since they were located in a market that was sucked dry of competent people (and, for the most part, even incompetent ones;), prices went up.
One of my co-workers who was hired in San Jose decided to relocate to the office I was working in. He got a handsome pay cut as a result to match the local living expenses/market conditions (but ended up better off due to cost-of-living)
Personally, I earn more now hourly, working less hours than I did for a.com (sometimes being reqiured to work 24 hour long shifts) while working outside of California. I don't get a pile of worthless stock options out of the deal, but at this point, being paid for the hours I work and being able to take vacation looks much more attractive.
Consider the source - Information Week is one of those thinly veiled advertisment magazines designed to trick your manager/CIO/etc into buying expensive "enterprise" software that barely works even after spending milllions in licensing and months of dedicated labor (often pushed as a "strategic" move to replace a working system.)
What I find most interesting, however, is that the author makes a jab at Linux while withholding any information which could be used to independently verify (and/or troubleshoot) his claims.
I've had the same problem, but in reverse, where Linux was working fine with a new system I had built, but Windows couldn't find half the devices. After getting the latest drivers for each component, I came to firmware. After updating the firmware for the motherboard chipset, Windows was happy and everything started working.
I suspect there is a similar situation at play here, but this time Linux is on the receiving end of the dodginess. Of course, the author obviously just wants to sling mud at Linux while shielding every other component which may be involved.
He could have just as easily asked why the sound card vendor wouldn't throw a bone to a project (eg., ALSA) that really wants to support any and every sound card. Or the whitebox vendor, if the same sound card worked in other systems.
There also needs to be a way to load bootstrap code remotely. For instance, having a TCP/IP enabled BIOS be able to run TFTP or some other protocol to load a netboot floppy image. Then you could give it a LILO command instructing it where to find a boot image, preferably one on a server in the same hosting center.
Coupled with with a terminal server/power management module such as
this you'll get all those features.
For x86 hardware, some vendors are shipping with serial console capabilities which include network booting, such as Dell's DRAC
Remote floppy boot. DRAC offers remote media access, allowing the server to boot from remote media. DRAC II uses floppy redirection. Administrators can insert a bootable DOS diskette into the diskette drive of the desktop machine and boot a remote server to that floppy. Administrators can then run operations from the floppy, including functions such as flash BIOS to recover servers with BIOS problems.
DRAC III uses Trivial File Transfer Protocol (TFTP) to transfer an image to the card and lets administrators enhance remote floppy performance by downloading floppy images to the memory on the card (see Figure 5 ). Functions on the "diskette" are executed in a DOS environment for 32-bit systems.
MOST of the time? These people are suing for $150,000 (the maximum copyright penalty) per download as often as they can. Under something like that, I can't afford to even take the RISK I might lose, even if I'm absolutely sure I'm in the clear.
That's an interesting point. If $150,000 is what they're claiming for each download, I think should be fairly easy to come up with a reasonable comparison to a real ballpark infringement amount.
iirc, KaZaa keeps track of how many uploads a user has done. For instance, if a user has 10,000 total uploads, a reasonable estimate would be $1/ea (the price on iTunes) for a total of $10,000.
Even if that were tripled, it would still yield $30,000 in this case.
If they're charging by song on the user's hard-disk and the user has 2,000 songs, that would come to $2000, or $6000 if tripled.
As it stands, they've sued 1500 people according to the article. If we use a lowball estimate of 500 songs per person, we come to about 112,500,000,000 (112 billion dollars).
Considering that the international music industry peaked at $40 billion in 2000, claiming that 1500 individuals (of millions) are responsible for nearly 3 times their peak revenue in damages is pretty clearly excessive. And, could be taken as downright intimidating (hence RICO and extortion).
And, the estimate above is obviously much lower than the actual aggregate amount when you take into account their lawsuit against four students for $97 billion into account (article here: http://www.theinquirer.net/?article=9380
)
For anyone still wondering, no, I'm not a lawyer.;)
It's interesting to see the different distributions slowly moving towards Debian's release policies. My question for the Fedora and now Mandrake is, why not utilize a very organized and effective "community" that exists right now of free software developers?
I think the problem with this scenario is that Debian's developers do what they want to, and can't just be "utilized" by a company. From what I saw in my years as a Debian user, Debian is more developer-oriented than user-oriented. For instance, NMU (non-maintainer updates) were a touchy subject, while a company like Mandrake is free to fix any package they want in official repository without ruffling feathers.
Of course, Debian developers are free to work on Mandrake Cooker as well... And, the distributions that are based on Debian exist, too. So far, I haven't noticed being Debian-based as a clear advantage in the marketplace, though. I don't see any real benefits of Mandrake shadowing Debian, personally.
Yes, some packages would be maintained well for no cost, but at the pace of, and in the style of the owning developer. Otherwise, Mandrake would have to maintain their own version, anyway. That could lead to working around Debian being far more work than just doing what they want to begin with.
For me as a user, that point was reached when Debian was still working on XFree86 4.1 months after the release of XFree86 4.2. My video card died, and after confirming with XFree86.org that I was getting a supported card and buying it, I noticed it required XFree86 4.2. XFree86 4.2 was not yet a part of Debian... not even in unstable, or on Branden's site. Meanwhile, Mandrake had already shipped with XFree86 4.2.
In such a situation, for Mandrake to release an updated XFree86 (or any core component, really) ahead of Debian proper, they would need to update and test each package depending X themselves.
Then they would be in the situation I mentioned above - having separate trees and trying to work with the official package maintainers to roll in their updates. All of that would burn through time which, imho, would be better spent building a distribution instead of fixing one.
I agree - with a problem of the magnitude of the LG drive bug, The Right Thing is to pull all the old ISOs and replace them with fixed ones. I'm disappointed by Mandrake tying this to Club Membership. Even though it wasn't technically their problem, it's bad karma (and, I'd even say bad business) to knowingly leave users exposed to that risk.
I think Mandrake's proposition is great, personally. I even suggested just this a while back:
Re: Quality Impact?
One of the main things I like about Mandrake is the up-to-dateness of everything in a standard release. I disagree about it being a renamed beta. After all, a beta can (and does) have changing versions the included software prior to release. Also, with betas, you're using software that is subject to serious change without much suport going from point A to point B. From what it looks like, this will be more like the FreeBSD -release branch, where only bugfixes and security updates are made to the previous release. And, there is a continual update path - just apply the update packages and you're there. No need to run the installer to install/upgrade each time as with a new beta.
I think this move helps reconcile the differences between catering to people like me, who use Mandrake at home and don't mind a few rough edges here and there (which I didn't even notice this time around) in order to get the latest and greatest with serious computing environments (i.e., servers) that need stable, tested software in order to effectively serve their purposes.
I think no matter what amount of pre-release testing they put into a release, it won't become seriously stable until it has been in the wild serving real-world needs. This just acknowledges that reality and solidifies it into a process.
Computers are never going to go away and they'll always need computer scientists.
The same could be said about toilets. Toilets are never going to go away, and they'll always need custodial engineers. The mere persistency of the field doesn't make it a wise career move from medicine.:-)
So you're another one locked into some pathetic semantic thing about what IE is part of. Doesn't it fit into your pet definition of an OS?
It was you who asked the question, and Microsoft who was adamant about it being part of the OS, not a bundled application.;) I personally don't have a pet definition of OS. Rather than push a definition as part of an agenda (my jargon is better than your jargon!) I'll accept the that words can have multiple related meanings, as seen in your favorite dictionary.:-)
Of course, Microsoft did have an agenda, and a reason to convince the court IE was part of their OS.
I'm just of the opinion that Microsoft don't fit the definition of a monopoly - and accordingly reject the rest of your arguments.
I was primarily answering your questions. Regardless of your opinion, there has been a court ruling on the matter.
You know it's funny, so many people saying they have no choice. Typing that whine into Mozilla running on Linux.
I'm typing into Galeon on Linux currently. I usually use Mozilla Firebird, but happened to start Galeon this time.
BeOS didn't run Windows applications... Stillborn, I'm afraid, because people use their OS to run their applications, not marvel at the number of video streams they can play simultaneously.
So, in one breath, you reject MS being a monopoly, and in the next, say that BeOS was stillborn because it didn't run Windows apps...;)
The point of mentioning it was to illustrate that, regardless of the merits of BeOS, Microsoft exerts considerable influence over the low-margin industry of making consumer PC's. If they don't want something to happen, like a mainstream vendor shipping BeOS, "preferred pricing" goes away and so does that PC vendor.
"DOS ain't done till Lotus won't run"... Hahaha... That's a good one. We're all still waiting for a cite for that one, of course.
The incident "DOS ain't done till Lotus won't run" refers to is covered in the book "Undocumented DOS", with supporting source code. Microsoft had changed DOS in such a way that Lotus ceased to function while Lotus was in their sights and they were pushing Excel.
It's just one example of that sort of behavior, like breaking Netscape with Windows 95 winsock and the error message about DR-DOS in the Windows 3.1 beta (complete with obfuscating code in an attempt to hide what they were up to)
You have already had it explained to you multiple times that you can install your own web browser, so the fact that IE is installed for you is irrelevant. You just need to stop whining about it, and we're done.
I've got my own web browser, indeed. Having MSIE bundled with Windows isn't irrelevant for me, though. I still have to ask people to disable "Show Friendly HTTP Error Messages" when they ask for help troubleshooting something while using IE, and deal with MSIE-isms because it's the dominant browser now... Of course, Microsoft's actions also helped lead to Mozilla being a really good and free (in both senses) browser. That doesn't change the fact that they used their monopoly influence to kill Netscape the company, though.
But who says Microsoft are just selling an operating system?
In the case of Windows, Microsoft does. In fact, that was the major thrust of their defense at their anti-trust trial - that MSIE was an integral part of the OS and not a bundled application.
They are selling the whole thing, applications and all. What is wrong with that? Why can't they sell what they like?
Trusts and monopolies are concentrations of wealth in the hands of a few. Such conglomerations of economic resources are thought to be injurious to the public and individuals because such trusts minimize, if not obliterate normal marketplace competition, and yield undesirable price controls. These, in turn, cause markets to stagnate and sap individual initiative.
To prevent trusts from creating restraints on trade or commerce and reducing competition, Congress passed the Sherman Antitrust Act in 1890. The Sherman Act was designed to maintain economic liberty, and to eliminate restraints on trade and competition. The Sherman Act is the main source of Antitrust law.
Back to AndrewHowe -
If other people want to sell alternative applications, then they need to make them better, or cheaper, or both. No-one is guaranteed that their business strategy will work.
The problem with leveraging monopolies is that potential competitors can't just make something better/cheaper/both and succeed. The monopolies can use underhanded tactics to prevent competition (like Microsoft was found guilty of doing)
If users don't look around for other software, then the producers of that other software are doing a bad marketing job.
Like BeOS, who offered the OS up to be bundled free with any computer? Or, with spreadsheets where "DOS ain't done till Lotus won't run"?
Why should Microsoft advertise for their competitors?
That's simply an option in case they want to enter another market without using their monopoly power. A poor option, imho, as it implies favoring the competitors who were able to leverage that...
Do you think that if I buy a car, it should come with no seats? That I should be forced to buy my own seats from elsewhere?
No. But, the auto industry isn't monopolized by a single company, so the point is moot. Also, the force is being applied to get you to take Internet Explorer from Microsoft.
A better example would be back in the days when you had to buy a telephone from the telco. Before that, a single company was in control of features, price, etc, of the telephone units that could be used.
Still, having tar with a z switch after all these years is just sick and wrong, imho. It's a simple feature to add, and the lack of it in proprietary Unix systems just goes to show they won't even go the extra inch for the user.
Re: compiler/ssh/etc being part of Linux, they are part of typical distributions, meaning they are supported as a part of the complete system, receive security updates using the standard system tools, etc.
Contrast, eg., Solaris, and xmkmf which are set up to use Sun's proprietary compiler (and makes compiling anything that uses imake quite a pain)
Slashdot Mirror
I think what most of what you're seeing is people having more attractive things to do than report spam.
Agreed, anything that depends on humans being perfect is flawed from the start. Luckily, code auditing is only part of OpenBSD's overall approach to security.
On the topic of protected memory by the OS, the OpenBSD team was right on top of W^X, and hounded Sun to get specs on their UltraSparc III processor to that end. Sun didn't co-operate, so they chose AMD64 as their platform of choice as it's also 64 bit and has W^X protection (including specs of how to use it, and is faster and cheaper than Sun gear!)
Since then, they've also come up with a way to get i386's memory protection (basically: don't execute anything above this address) to do something useful. The OpenBSD linker re-arranges code and data, so the code comes first followed by the data. That way, the execution boundary can be set at the end of the code. Oppose how other operating systems handle i386 - code and data are mixed together, so the i386 memory protection is useless.
Other niceties are propolice, a stack protection tool being enabled by default. Shared libraries being shuffled by the linker so an attacker that depends on a specific memory address for a library, or a chain of libraries will have a much harder time. Privilege separation is pervasive throughout the OS (both dropping to a non-root user to perform tasks which don't require root and chrooting - eg, there is a _tcpdump user for processing packets once the steps requiring root have been done)
I feel this pain, too. For me, the problem has been with hardware support for SCSI/RAID controllers. That was some time ago, though and that particular item looks like it's mostly addressed provided careful selection of components. In any case, I still am able to benefit by using OpenBSD to do firewalling and DNS.
However, most of the techniques I mentioned are relatively low-hanging fruit other operating systems could easily pick were they interested. After all, the hard part of developing the techniques and getting them working has already been done. Now there is a working example to study, and most of the code is BSD licensed.
Understood. I was speaking of practicality. It would be illegal for them to randomly snoop around, grabbing anything that looks interesting, too, if all they were supposed to be doing was installing patches and doing virus scans.
Giving a college employee (who is likely a student) access to run any program with administrator rights is ripe for abuse. Even if this is limited to running a batch file daily (or weekly or ...) it would be trivial to add functionality to, for instance, copy all .gif files to look for an off color photo of any of the female students... or delete a research paper, install a keylogger, (re)enable a webcam's image capturing to see what you were missing while the owner thought it was off etc.
Of course, you also mentioned the problem of the machine giving out all these patches being compromised. Even if your college were lucky enough to find someone honest enough to not do anything intentionally evil, compromise of that one machine would provide the attacker access to run anything as administrator on all connected systems.
This is reminiscent of landlord/tenant laws. The landlord is required to give notice before entering someone's living space. And similar to the difference between department stores monitoring their dressing rooms for shoplifting vs. your landlord putting a camera into your bedroom and bathroom "to make sure you aren't using drugs / damaging anything/etc"
It may be legal for the college to do this, but certainly isn't something it should be doing.
Anyway, I'd be configuring VMWare run the university-accessible copy of Windows and only use that for NAT. Anything you send over their network cleartext is fair game, anyway.
Also, over the long-term, being a Linux user who runs a Windows program does tend toward sticking it to Microsoft. Spending full-time in the Linux user environment with one nagging dependency is a clearer path to ultimate independence from Windows-based software; As a full-time Linux user, the itch is to get rid of that Windows dependency. As a dual boot user, the tendency is to stay in the currently booted environment until you want something in the other environment enough to close everything and reboot.
Not to mention the practical benefits of spending as little time as possible in a breeding ground for viruses and other malware... or the network effect of the existence of more full-time Linux users, (some of whom happen to run a program under win4lin). :-)
Only then will we be safe from another 9/11.
Basically, what they are doing is getting coffee shops to pay a small fee to host the access points (running a custom Linux configuration), networking those, and offering both the internet connection on the coffee house's dime and building out their own BBS-like intranet service.
Maybe the idea would be harder to get off the ground in other parts of the world, but if you can swing it, I think internet access is a big draw for people who otherwise may not bother.
For instance, OpenBSD releases on a 6 month schedule, usually keeps source-based upgrades working (except in the case of binary executable format changes), and is really tilted toward improving security.
NetBSD, while also a nice OS (the first free unix w/ USB support, and had wireless going seamlessly - both release quality and stable long before LInux) it doesn't feel the same as an admin. Source updates aren't supported, you don't get everything chrooted and locked down by default, and new releases aren't tied to any schedule.
If you want SMP on BSD, FreeBSD has been there for years, and also sticks to a regular release schedule. Since it has a large community surrounding it, it also has nice things like Binary Updates
Oops, bad math..
At 600 barrels crude/day/ea for these plants, it would take 16 and 2/3rd's of these to feed a 10,000 bcd/refinery.
Of course, if they can scale this and apply it to other types of waste as mentioned (so they don't run out of turkeys!) it could become a valuable alternative crude oil source... But probably not poised to replace petroleum imports in the near future.
In any case, getting a useful product out of what started as 200 tons / day of thrown out turkey parts is useful on its own, and could definitely tilt the scales toward cost-effectiveness.
I have no idea how that translates to fiscal feasibility, but Con-Agra, the other party to the joint-venture is as an old, well-established agricultural company (i.e., not a startup whose primary business is selling shares) And, they actually have generated saleable oil.
On the other hand, they're touting this more as a waste management technique more than an energy source. The pilot plant is producing 100-200 barrels/day (with a 600 theoretical limit). A quick google search shows refineries processing 10,000 - 437,000 barrels crude/day
So, it would take 100 of these plants to feed the smallest of those refineries.
No, I'm not sure. Don't mistake me for an expert on this set of vulnerabilities. I was going by what was said in the link and on the OpenBSD misc@ mailing list.
...right? ;)
According to some messages on the list, Cisco was one of the worst affected by the recently announced set of TCP vulnerabilities, and OpenBSD had only minimal exposure in the first place.
It strikes me that this may be PR ploy on Cisco's part to cover up for their past mistakes by appearing to rush to the rescue with a patent pending solution. They'll even graciously let others use them in exchange for cross-licensing. After all, if it's pending a patent, those Cisco guys must be really on the ball
Personally, I trust the OpenBSD project a great deal more than Cisco when it comes to security. I mean, OpenBSD wasn't even vulnerable to the no-workaround backdoor password issue!
Luckily in that case, locking a user account had a considerable amount of prior art.
This is the second time in six months OpenBSD has seriously one-upped Cisco and its patents. :-) They even wrote a song about the first!
I picked up OpenBSD with version 2.3 and started using it seriously with version 2.5. During that time, it has gone from being an audited and secure (but otherwise fairly plain) OS to a compelling system with a wide range of complementary features.
;)
:-)
The ones that stand out for me are -
Chrooting and dropping privileges for BIND by default (kept me feeling fairly safe through a few vulnerabilities, and without the extra work of maintaining my own bind built for chroot)
Picking up ssh and releasing a good, free version
Coming up with the nicest firewall I've used, taking it from nothing to ready for release within 6 months (That still amazes me!)
spamd - After breaking 400 spam messages a day directed at my inbox, wiring Spamhaus SBL into the firewall and tarpitting a good portion of the traffic is a nice bonus. Noticing a week after setting that up that OpenBSD 3.5 has graylisting is a nice surprise.
Propolice stack protection built into the OS and integrated for the long haul
Now with CARP, I can feel comfortable getting all this in any environment - I think failover support really opens up a lot of possibilities for the future of OpenBSD.
All in all, OpenBSD has all the attributes I like in an OS -
regular 6 month releases (production quality doesn't have to mean stale),
cohesiveness (no waiting for glibc to catch up to a new kernel feature, or vice-versa),
a real commitment to free software (as demonstrated with OpenSSH, pf, and now CARP)
really delivering - as opposed to various Linux security projects that I've seen integrated with mainstream distros, then apparently forgotten about or relegated to a special option marked with a warning label, OpenBSD is a real tested system.
As a system, it can progress toward its goals through every aspect of the system (eg., the pervasive privilege separation), rather than a patchset to a mainstream distro, which has inherent lag time and may be working at cross-purposes to that distro or the numerous projects that make up the distro it's trying to secure. I've seen a few patchsets come and go over the years, too, while OpenBSD keeps adding to the foundation they've built.
Thanks, OpenBSD team, for all the great releases... (and all the fish
Now I'm off to explore my new OpenBSD 3.5 system, where make build just finished.
Windows:
The only Windows I use is Windows XP Professional as a unix admin in a corporation, so some items may be notably absent. My entire Windows list is software that can be used royalty-free for commercial use )with an obvious emphasis on Free Software).
For example, I use XFree86 shipped with Cygwin for my X server, WinSCP for secure file transfer, Spybot S&D (and not AdAware, which is another excellent product, but would require a licensing fee be paid).
I don't use Winzip at all, since that functionality is built into the explorer interface in Windows XP Professional (don't know about the others), and is also available through Cygwin.
On the occasion I'm visiting a friend who runs Windows on a personal desktop, I also recommend Zinf, the audio player, since it's free software and just plays the music without any corporate spyware tie-ins, eg., contacting a server based on mp3 header fields as WMP and Winamp have started doing.
During the .com bubble, I worked for a company headquartered in San Jose, and the business climate there was downright hostile. Difficult to rent rooms, get flights, office space (for startups, this usually involved huge rents + giving up part of the company)
Of course, this also extended itself to labor. Since the cost of living had been driven up so high by all of those companies basing their operations there, and since they were located in a market that was sucked dry of competent people (and, for the most part, even incompetent ones ;), prices went up.
One of my co-workers who was hired in San Jose decided to relocate to the office I was working in. He got a handsome pay cut as a result to match the local living expenses/market conditions (but ended up better off due to cost-of-living)
Personally, I earn more now hourly, working less hours than I did for a .com (sometimes being reqiured to work 24 hour long shifts) while working outside of California. I don't get a pile of worthless stock options out of the deal, but at this point, being paid for the hours I work and being able to take vacation looks much more attractive.
What I find most interesting, however, is that the author makes a jab at Linux while withholding any information which could be used to independently verify (and/or troubleshoot) his claims.
I've had the same problem, but in reverse, where Linux was working fine with a new system I had built, but Windows couldn't find half the devices. After getting the latest drivers for each component, I came to firmware. After updating the firmware for the motherboard chipset, Windows was happy and everything started working.
I suspect there is a similar situation at play here, but this time Linux is on the receiving end of the dodginess. Of course, the author obviously just wants to sling mud at Linux while shielding every other component which may be involved.
He could have just as easily asked why the sound card vendor wouldn't throw a bone to a project (eg., ALSA) that really wants to support any and every sound card. Or the whitebox vendor, if the same sound card worked in other systems.
Sun hardware has had serial consoles that can boot from the network for years. The syntax for the current OBP (OpenBoot PROM) revisions is here: http://docs.sun.com/db/doc/817-2701/6mibjioqr?a=vi ew
Coupled with with a terminal server/power management module such as this you'll get all those features.
For x86 hardware, some vendors are shipping with serial console capabilities which include network booting, such as Dell's DRAC
iirc, KaZaa keeps track of how many uploads a user has done. For instance, if a user has 10,000 total uploads, a reasonable estimate would be $1/ea (the price on iTunes) for a total of $10,000.
Even if that were tripled, it would still yield $30,000 in this case.
If they're charging by song on the user's hard-disk and the user has 2,000 songs, that would come to $2000, or $6000 if tripled.
As it stands, they've sued 1500 people according to the article. If we use a lowball estimate of 500 songs per person, we come to about 112,500,000,000 (112 billion dollars).
Considering that the international music industry peaked at $40 billion in 2000, claiming that 1500 individuals (of millions) are responsible for nearly 3 times their peak revenue in damages is pretty clearly excessive. And, could be taken as downright intimidating (hence RICO and extortion).
And, the estimate above is obviously much lower than the actual aggregate amount when you take into account their lawsuit against four students for $97 billion into account (article here: http://www.theinquirer.net/?article=9380 )
For anyone still wondering, no, I'm not a lawyer. ;)
I think the problem with this scenario is that Debian's developers do what they want to, and can't just be "utilized" by a company. From what I saw in my years as a Debian user, Debian is more developer-oriented than user-oriented. For instance, NMU (non-maintainer updates) were a touchy subject, while a company like Mandrake is free to fix any package they want in official repository without ruffling feathers.
Of course, Debian developers are free to work on Mandrake Cooker as well... And, the distributions that are based on Debian exist, too. So far, I haven't noticed being Debian-based as a clear advantage in the marketplace, though. I don't see any real benefits of Mandrake shadowing Debian, personally.
Yes, some packages would be maintained well for no cost, but at the pace of, and in the style of the owning developer. Otherwise, Mandrake would have to maintain their own version, anyway. That could lead to working around Debian being far more work than just doing what they want to begin with.
For me as a user, that point was reached when Debian was still working on XFree86 4.1 months after the release of XFree86 4.2. My video card died, and after confirming with XFree86.org that I was getting a supported card and buying it, I noticed it required XFree86 4.2. XFree86 4.2 was not yet a part of Debian ... not even in unstable, or on Branden's site. Meanwhile, Mandrake had already shipped with XFree86 4.2.
In such a situation, for Mandrake to release an updated XFree86 (or any core component, really) ahead of Debian proper, they would need to update and test each package depending X themselves.
Then they would be in the situation I mentioned above - having separate trees and trying to work with the official package maintainers to roll in their updates. All of that would burn through time which, imho, would be better spent building a distribution instead of fixing one.
I agree - with a problem of the magnitude of the LG drive bug, The Right Thing is to pull all the old ISOs and replace them with fixed ones. I'm disappointed by Mandrake tying this to Club Membership. Even though it wasn't technically their problem, it's bad karma (and, I'd even say bad business) to knowingly leave users exposed to that risk.
One of the main things I like about Mandrake is the up-to-dateness of everything in a standard release. I disagree about it being a renamed beta. After all, a beta can (and does) have changing versions the included software prior to release. Also, with betas, you're using software that is subject to serious change without much suport going from point A to point B. From what it looks like, this will be more like the FreeBSD -release branch, where only bugfixes and security updates are made to the previous release. And, there is a continual update path - just apply the update packages and you're there. No need to run the installer to install/upgrade each time as with a new beta.
I think this move helps reconcile the differences between catering to people like me, who use Mandrake at home and don't mind a few rough edges here and there (which I didn't even notice this time around) in order to get the latest and greatest with serious computing environments (i.e., servers) that need stable, tested software in order to effectively serve their purposes.
I think no matter what amount of pre-release testing they put into a release, it won't become seriously stable until it has been in the wild serving real-world needs. This just acknowledges that reality and solidifies it into a process.
Of course, Microsoft did have an agenda, and a reason to convince the court IE was part of their OS.
I was primarily answering your questions. Regardless of your opinion, there has been a court ruling on the matter. I'm typing into Galeon on Linux currently. I usually use Mozilla Firebird, but happened to start Galeon this time. So, in one breath, you reject MS being a monopoly, and in the next, say that BeOS was stillborn because it didn't run Windows apps...The point of mentioning it was to illustrate that, regardless of the merits of BeOS, Microsoft exerts considerable influence over the low-margin industry of making consumer PC's. If they don't want something to happen, like a mainstream vendor shipping BeOS, "preferred pricing" goes away and so does that PC vendor.
The incident "DOS ain't done till Lotus won't run" refers to is covered in the book "Undocumented DOS", with supporting source code. Microsoft had changed DOS in such a way that Lotus ceased to function while Lotus was in their sights and they were pushing Excel.It's just one example of that sort of behavior, like breaking Netscape with Windows 95 winsock and the error message about DR-DOS in the Windows 3.1 beta (complete with obfuscating code in an attempt to hide what they were up to)
I've got my own web browser, indeed. Having MSIE bundled with Windows isn't irrelevant for me, though. I still have to ask people to disable "Show Friendly HTTP Error Messages" when they ask for help troubleshooting something while using IE, and deal with MSIE-isms because it's the dominant browser now... Of course, Microsoft's actions also helped lead to Mozilla being a really good and free (in both senses) browser. That doesn't change the fact that they used their monopoly influence to kill Netscape the company, though.A better example would be back in the days when you had to buy a telephone from the telco. Before that, a single company was in control of features, price, etc, of the telephone units that could be used.
Yes, I'm aware of
gzip -cd foo.tar.gz | tar xvf -
Still, having tar with a z switch after all these years is just sick and wrong, imho. It's a simple feature to add, and the lack of it in proprietary Unix systems just goes to show they won't even go the extra inch for the user.
Re: compiler/ssh/etc being part of Linux, they are part of typical distributions, meaning they are supported as a part of the complete system, receive security updates using the standard system tools, etc.
Contrast, eg., Solaris, and xmkmf which are set up to use Sun's proprietary compiler (and makes compiling anything that uses imake quite a pain)