In contrast, users of Amazon's S3 pay Amazon more the more that they scale up.
Actually they pay less. Who would use a business that got costlier at larger scales?
No, they pay less per unit storage, they pay more in total. Once they're using more than 5000TB/month, it the amount per unit storage stays constant. To ask your question in reverse, why would Amazon offer a service that they got paid less for the more you used it?
Amazon is not selling them something at a fixed price, it is selling them a service that takes some percentage of their income. If an S3 customer becomes successful and their revenue goes from $1,000 to $1,000,000 then Amazon's income also increases by a factor of a thousand.
Are you serious? Is this trolling? Are you a kid?
I'm quite serious. I'm oversimplifying slightly, of course, because the per-unit amount does decrease from $0.140 / GB / month to $0.055 / GB / month as the amount stored (although you're still paying the higher amount for the first TB month). The amount that Amazon makes from Dropbox is likely to be several orders of magnitude more than they make from, for example, tarsnap.
Re:How similar to PC-BSD as far as simplicity?
on
FreeBSD 9.0 Released
·
· Score: 1
FreeBSD 9.0 has the ports system, which is great for installing things from source and pkg_add which lets you install packages from binaries. Usually. And sometimes it actually works. Maybe.
9.1 should ship with pkgng, which is a long-overdue replacement for the binary package system, which learns from the things that apt and friends do well and the things that they don't. Hopefully by FreeBSD 10, pkgng will also be handling the more modular parts of the base system.
I have a NAS with 6TB of disks and 8GB of RAM, with one filesystem being deduplicated (the one where Time Machine sticks backups with loads of duplicates, currently about 300GB of data). I've not done any manual tuning, and I've not noticed the issues that you talk about...
FreeBSD vs Linux (unless you are using something like ZFS) probably won't see a huge difference in memory usage. Something like FireFox or OpenOffice will use a lot more memory than either kernel, and will use the same amount on either.
I'll have to read up on Capsicum. I can't tell if it is an enhancement to jails or a replacement.
It's neither, it's an orthogonal system. It's also insanely easy for developers to use. You call cap_enter(), and from that point on you may not touch the filesystem except via file descriptors you already have open or are passed by another process. Your process is then sandboxed, as every interaction with things outside of a process in UNIX happen via file descriptors. If it has a file descriptor for a directory, then it can use open_at() and friends to open files in that directory, but it can't touch arbitrary parts of the FS. You can also use cap_new() to create a new file descriptor from an existing one that has reduced privileges (e.g. read-only), so it is pretty trivial for a lot of applications to have access to the small set of things that they need and nothing else.
One of the first applications to be modified to use Capsicum was Chromium. It took about 300 lines of code to make Chromium's sandboxing system use it, so each browser window runs with the absolute minimum of privilege that it needs. Various tools in the base system are being modified to use it, as are ports.
Apple sells a proprietary software stack. Apple developers have contributed over 200,000 lines of code to LLVM / Clang and related projects. Developers at companies like Adobe have also contributed code. This is what we call cooperation in the BSD community. Sure, it's not the same sort of cooperation as companies enjoy with the the GPL community, where they are berated if they keep a single line of code proprietary until they eventually give up and move to a 100% proprietary stack, but we like it.
you could try building Darwin from source, and get the drivers you need for your hardware
Last time I checked, the entire sound subsystem on OS X was proprietary. I suppose you might be able to port OSS to XNU, but until then you'd have an OS with no audio.
You keep posting that Wikipedia link, but you really should look up what the doctrine of latches actually says in patent law. Simply put, it means that you can't claim any damages that occurred between first discovering infringement and notifying the infringing party. You can, for example, file a patent, see someone start to infringe, wait for 10 years as they grow in market share, and then sue them and require payment for every subsequent device that they sell. What you can't do is claim damages from this ten year period.
BSD people WANT PEOPLE to take their code and use it for commercial development
I wouldn't say that. I don't want people to take my code and use it in commercial development - I just don't care if they do. I do, however, want people to contribute bug fixes (or even bug reports with helpful test cases) for my code, and ideally new features. The more people using my code, the more likely it is that some people will do this. If people can use it without having to open everything that they're doing, then they're more likely to use it, and it's generally easier for them to contribute changes back than maintain a fork. People who take the code and contribute nothing back are totally irrelevant to me: there is no difference to me whether someone uses my code and gives nothing back or writes a proprietary replacement, except that in the former case they are more likely to pay for my services as a programmer at some later point.
The only problem is that the GPLv3 closed "loopholes" that previously allowed appliance manufacturers to ship FreeBSD-based boxes as-is under the GPLv2
Actually, a lot of downstream people didn't like GPLv2 either, but there were no feasible alternatives for a lot of things available 5 years ago. The new patent clauses in GPLv3 mean a lot of companies won't let it in the door, in case they end up accidentally giving out a free license to all of their patents by distributing some GPLv3 code (imagine how fucked one of the companies involved in the current mobile phone patent war would have been if they'd distributed GPLv3 code and lost their defensive portfolio as a result).
they're sticking to the GPLv2 for every software in the base system
FreeBSD has not imported any GPLv3 code into the base system. FreeBSD 10 aims to remove all of the GPLv2 code as well.
As a user and if I were to complain, I'd say that it's regrettable that some developers are required to do some NIH work instead of improving or adding features just because of license wars
It is unfortunate, but it also has some advantages. A lot of the GPL'd code in base is, quite frankly, crap. The fact that it's EOL'd upstream means that there is now a solid justification for a complete rewrite. For example, clang is a lot more modular than gcc. When I was implementing the new reentrant locale functions in FreeBSD libc, I wrote a little tool using the clang libraries checked that none of the reentrant functions called any non-reentrant functions or accessed any mutable shared state. This was about 100 lines of code with clang, but would have been insanely hard with gcc. The new STL implementation, libc++, provides C++11 support and, more interestingly, is written in C++11 and so can use things like r-value references internally for better performance (or to avoid needing ugly hacks to emulate them). Since it's written from scratch for modern platforms, it's optimised for the performance characteristics of modern platforms, while GNU libstdc++ is optimised for the hardware that was around 10-20 years ago.
By writing more GPL software, we are pushing companies to write more proprietary software that duplicates functionality and for which they will file for patents.
And you're encouraging the idea that Free Software is an all or nothing proposition. With the GPL, a company has the choice of releasing everything or releasing nothing. With permissively licensed code, they can easily contribute things that are not directly related to their core business and keep other things proprietary. Once they've done this, it's easier to encourage them to gradually expand the the set of things that they are releasing.
Personally, I would rather a company be encouraged to release some of its code back to the community than they be encouraged to keep everything proprietary.
I should probably add the disclaimer that I am the author of the wiki page that the original poster in this thread cited...
It's not a sense of entitlement, it's a desire to reach a situation where everyone receives the maximum benefit. Here's a concrete example for you:
I write a lot of Objective-C code that runs on a variety of platforms (developed on FreeBSD, but it runs on Linux, apparently someone uses some of it on Solaris, and so on). I want a decent Objective-C compiler. Apple also wants a decent Objective-C compiler, and they want to be able to reuse the parser in their (proprietary) IDE and a few other tools.
Apple was shipping GCC as their compiler, but the GPL meant that they couldn't use the parser for syntax highlighting or refactoring tools in their IDE without having to GPL the whole thing. So they started working on a new front end which they released under a BSD-like license and I contributed quite a few improvements and bug fixes. Apple got a few days worth of free work out of me, I got a few man-years of free work out of them. Both of us benefitted. They can keep their IDE proprietary, and I can use a high-quality Objective-C compiler on FreeBSD.
The GPL meant that they couldn't use the code as they wanted, so their only choice was to rewrite it completely. Note that this isn't limited to proprietary software: GPLv2 is incompatible with things like the Apache and Mozilla licenses, so if you want to use a library under one of these then you can't use GPLv2 code. GPLv3 comes with some patent licensing clauses that mean that a lot of companies won't let it in the door.
FreeBSD is okay on laptops, the current issue if video cards. nVidia still releases blob drivers for FreeBSD, but the latest Intel and AMD drivers rely on things like GEM/TTM/KMS that are Linux-specific. There is currently a FreeBSD Foundation-funded project underway to provide all of the kernel support that the Intel drivers need, but the AMD drivers are going to take a bit longer...
That's not quite the same. The tool sellers had a little risk, but not a huge return. You can sell spades to 1,000 prospectors, but the one who strikes gold will probably make a lot more than you. In contrast, users of Amazon's S3 pay Amazon more the more that they scale up. Amazon is not selling them something at a fixed price, it is selling them a service that takes some percentage of their income. If an S3 customer becomes successful and their revenue goes from $1,000 to $1,000,000 then Amazon's income also increases by a factor of a thousand.
That's the point of using open protocols. The service should not support the operating system, the service provider and the operating system provider should both support the same protocol. For example, if you have a WebDAV server running somewhere then pretty much any modern operating system can mount it.
In the '90s, every Windows user installed WinZIP (a few even paid for it!). Everyone distributed zip files and WinZIP was the tool for opening and creating them. It wasn't a sexy market, but it was a solution to a problem that a lot of people had, and it was the tool that everyone used (except warez d00dz, who preferred rar). The, Windows came with the ability to explore zip files as if they were normal folders. The need for WinZIP dropped from almost everyone to practically no one overnight. The same thing happened on the Mac with StuffIt - OS X can natively open a variety of archive formats, so there is no need for a third-party tool.
Fast forward a decade, and DropBox is in the same position in the cloud storage market that WinZIP occupied in its own market. Everyone who needs to share a couple of files with a friend or colleague uses it. But now operating systems and other services are coming with some cloud storage, so there's less need for a third-party service.
LENR is not cold fusion. LENR is a broad category and basically means 'stuff that is not high-energy fission / fusion.' It includes neutron capture (i.e. a neutron hits a nucleus, is absorbed, and no fission occurs) and radioactive decay. There are a lot of LENR generators. Some pacemakers contain betavoltaic generators that are powered by a small quantity of tritium. The Russians used to power lighthouses with radiothermal generators (RTFs) and there are three of them powering each of the Voyager spacecraft, with a rated lifespan of about 60 years each.
eCat sounds like they are claiming two low-energy reactions: a neutron capture followed by a decay. This is potentially feasible, but then good snake oil is always feasible...
The McCarthy era also provides a lot of counterexamples to the argument 'I'm not doing anything I'm ashamed of, why should I care?' Consider the person who, during the Second World War was involved with a charity to send aid to parts of Russia recovering from the Nazi invasion. At the time, the USSR and the USA were allies. These people were involved in sending food and medical supplies to one of their allies in a time of war: surely nothing to be ashamed of? But then, just a little bit later, the USSR was the Evil Empire and anyone who supported it in any way was an evil communist and a traitor. The House Committee on Unamerican Activities would look at this charitable donation as evidence of communist sympathies and you could lose your job and be alienated from your friends.
Which is why, in my original post, I said that the government should be structuring laws to encourage innovative business models like this, rather than trying to prop up ones that have no long-term future. Creating software (or art) is difficult. Copying and distributing it is easier than it was and is getting easier all of the time. Any business model that depends on doing the difficult bit for free and then charging for the easy bit is doomed to failure in the long run.
Here's the obligatory car analogy: Imagine if a car company would give you a car for free and charge $20,000 to paint it for you. Now imagine if this was the established business model that all car companies used and there were laws in place saying that unpainted cars could not be used on the road and that only the car manufacturer was allowed to paint the cars that they made. Initially, car painting used expensive paints and required some complex techniques. Now, anyone can do it with a hundred dollars or so of equipment and paint. In a few years, drive-through car painting services are going to be possible costing under $20 for a new coat of paint, but the car industry is refusing to change their business model and insisting that the government impose strict distribution controls on all of the materials that can be used to make car paints.
That's more or less the situation that we're in with copyright. The established players are tied to a doomed business model and they'd rather break the rest of the economy than adapt.
No recent open source AMD ones either. The recent open source AMD and Intel 'X.org' drivers are so full of Linux kernel dependencies that it's difficult to port them. This is a shame, because a lot of smaller operating systems (e.g. Haiku) base their 3D support off FreeBSD's DRI port. There is currently work underway to support the stuff needed for the Intel drivers, but AMD ones are a bit further away. The nVidia blob drivers are the best supported by FreeBSD.
If anyone at AMD or Intel is reading this: please get your driver team to pay a bit of attention to portability...
Re:A nice KDE implementation, but...
on
PC-BSD 9.0 Release
·
· Score: 4, Informative
I guess, but for normal desktop use is there really much to gain? These are 'desktop' distros/respins we're talking about here. I run ext4 on my main workstation and am happy.
ZFS is one of those things that you don't really appreciate until you've used it. Creating ZFS filesystems is about as hard as creating new directories, so with ZFS you generally create a lot of filesystems - they're dynamically sized, so the typical downside of this is not there.
Turning on compression or deduplication, or maybe encryption, for a particular filesystem is a single command. If you've got some really important data then you can tell it to store multiple copies on a single disk, so block-level errors are recoverable, not just detectable, even without RAID.
The most useful feature, however, is snapshots. It's trivial to set up a cron job that snapshots a filesystem every day, hour, or whatever. Ever deleted a file by mistake, or had a program error corrupt a document? With automatic snapshots, you can simply mount the old version of the filesystem and restore it. I think GNOME has a GUI for this (Time Slider or something) letting you just move a slider to go back to an earlier state of a filesystem.
It's also great for testing. Not sure if something is safe to run? Clone the filesystem, try it, and then destroy the clone and do it on the live fs. Or, if nothing else will be modifying the filesystem, just snapshot, run it, and roll back if it doesn't work.
On FreeBSD, ZFS integrates nicely with jails (on Solaris, s/jails/zones) so you can run untrusted programs in a jail by just cloning a jail that's set up for test systems and then throwing it away at the end.
Snapshots and clones in ZFS are cheap to create. It stores everything using reference counting and copy-on-write semantics, so all you need to do to create a clone is increment a reference count for a filesystem root. Modifications to either the clone or the original will create new copies of the files (they will anyway, because ZFS supports transactional I/O, so the FS is always in a consistent state).
Re:Just out of curiosity
on
PC-BSD 9.0 Release
·
· Score: 5, Informative
One big thing you will notice is that the BSD teams are a bit less deprecation-happy than Linux developers. Over in Linux land, components seem to have two states: unfinished and deprecated. BSDs tend not to replace things that work, tend to favour incremental improvements over complete rewrites, and care a lot about interface stability. Most of the administrative stuff I learned when I first used FreeBSD a decade ago is still valid now - the implementations have changed a lot, but the tools still appear to act the same way. They also put a lot of effort into maintaining binary compatibility for the core system.
Most employers recognize you working-class-hero types are 90% garbage. Holding out for a proper solution would realistically mean it would never get done.
Bullshit, and probably an intentional troll that I've fallen for.
Most businesses do a cost-benefit analysis. Given the choice of doing a solution that kind-of works in two months and one that works well in two years, the first gives you 22 months of income from selling your products / services before the second is ready and costs a lot less. It's only industries like aerospace, where a product failure is very expensive that you have the luxury of doing things properly.
Slashdot Mirror
In contrast, users of Amazon's S3 pay Amazon more the more that they scale up.
Actually they pay less. Who would use a business that got costlier at larger scales?
No, they pay less per unit storage, they pay more in total. Once they're using more than 5000TB/month, it the amount per unit storage stays constant. To ask your question in reverse, why would Amazon offer a service that they got paid less for the more you used it?
Amazon is not selling them something at a fixed price, it is selling them a service that takes some percentage of their income. If an S3 customer becomes successful and their revenue goes from $1,000 to $1,000,000 then Amazon's income also increases by a factor of a thousand.
Are you serious? Is this trolling? Are you a kid?
I'm quite serious. I'm oversimplifying slightly, of course, because the per-unit amount does decrease from $0.140 / GB / month to $0.055 / GB / month as the amount stored (although you're still paying the higher amount for the first TB month). The amount that Amazon makes from Dropbox is likely to be several orders of magnitude more than they make from, for example, tarsnap.
FreeBSD 9.0 has the ports system, which is great for installing things from source and pkg_add which lets you install packages from binaries. Usually. And sometimes it actually works. Maybe.
9.1 should ship with pkgng, which is a long-overdue replacement for the binary package system, which learns from the things that apt and friends do well and the things that they don't. Hopefully by FreeBSD 10, pkgng will also be handling the more modular parts of the base system.
It's not just Lennart Poettring. There's also no Ulrich Drepper either! On the down side, OpenBSD has Theo De Raadt, and FreeBSD has me...
I have a NAS with 6TB of disks and 8GB of RAM, with one filesystem being deduplicated (the one where Time Machine sticks backups with loads of duplicates, currently about 300GB of data). I've not done any manual tuning, and I've not noticed the issues that you talk about...
FreeBSD vs Linux (unless you are using something like ZFS) probably won't see a huge difference in memory usage. Something like FireFox or OpenOffice will use a lot more memory than either kernel, and will use the same amount on either.
I'll have to read up on Capsicum. I can't tell if it is an enhancement to jails or a replacement.
It's neither, it's an orthogonal system. It's also insanely easy for developers to use. You call cap_enter(), and from that point on you may not touch the filesystem except via file descriptors you already have open or are passed by another process. Your process is then sandboxed, as every interaction with things outside of a process in UNIX happen via file descriptors. If it has a file descriptor for a directory, then it can use open_at() and friends to open files in that directory, but it can't touch arbitrary parts of the FS. You can also use cap_new() to create a new file descriptor from an existing one that has reduced privileges (e.g. read-only), so it is pretty trivial for a lot of applications to have access to the small set of things that they need and nothing else.
One of the first applications to be modified to use Capsicum was Chromium. It took about 300 lines of code to make Chromium's sandboxing system use it, so each browser window runs with the absolute minimum of privilege that it needs. Various tools in the base system are being modified to use it, as are ports.
Apple sells a proprietary software stack. Apple developers have contributed over 200,000 lines of code to LLVM / Clang and related projects. Developers at companies like Adobe have also contributed code. This is what we call cooperation in the BSD community. Sure, it's not the same sort of cooperation as companies enjoy with the the GPL community, where they are berated if they keep a single line of code proprietary until they eventually give up and move to a 100% proprietary stack, but we like it.
you could try building Darwin from source, and get the drivers you need for your hardware
Last time I checked, the entire sound subsystem on OS X was proprietary. I suppose you might be able to port OSS to XNU, but until then you'd have an OS with no audio.
You keep posting that Wikipedia link, but you really should look up what the doctrine of latches actually says in patent law. Simply put, it means that you can't claim any damages that occurred between first discovering infringement and notifying the infringing party. You can, for example, file a patent, see someone start to infringe, wait for 10 years as they grow in market share, and then sue them and require payment for every subsequent device that they sell. What you can't do is claim damages from this ten year period.
BSD people WANT PEOPLE to take their code and use it for commercial development
I wouldn't say that. I don't want people to take my code and use it in commercial development - I just don't care if they do. I do, however, want people to contribute bug fixes (or even bug reports with helpful test cases) for my code, and ideally new features. The more people using my code, the more likely it is that some people will do this. If people can use it without having to open everything that they're doing, then they're more likely to use it, and it's generally easier for them to contribute changes back than maintain a fork. People who take the code and contribute nothing back are totally irrelevant to me: there is no difference to me whether someone uses my code and gives nothing back or writes a proprietary replacement, except that in the former case they are more likely to pay for my services as a programmer at some later point.
The only problem is that the GPLv3 closed "loopholes" that previously allowed appliance manufacturers to ship FreeBSD-based boxes as-is under the GPLv2
Actually, a lot of downstream people didn't like GPLv2 either, but there were no feasible alternatives for a lot of things available 5 years ago. The new patent clauses in GPLv3 mean a lot of companies won't let it in the door, in case they end up accidentally giving out a free license to all of their patents by distributing some GPLv3 code (imagine how fucked one of the companies involved in the current mobile phone patent war would have been if they'd distributed GPLv3 code and lost their defensive portfolio as a result).
they're sticking to the GPLv2 for every software in the base system
FreeBSD has not imported any GPLv3 code into the base system. FreeBSD 10 aims to remove all of the GPLv2 code as well.
As a user and if I were to complain, I'd say that it's regrettable that some developers are required to do some NIH work instead of improving or adding features just because of license wars
It is unfortunate, but it also has some advantages. A lot of the GPL'd code in base is, quite frankly, crap. The fact that it's EOL'd upstream means that there is now a solid justification for a complete rewrite. For example, clang is a lot more modular than gcc. When I was implementing the new reentrant locale functions in FreeBSD libc, I wrote a little tool using the clang libraries checked that none of the reentrant functions called any non-reentrant functions or accessed any mutable shared state. This was about 100 lines of code with clang, but would have been insanely hard with gcc. The new STL implementation, libc++, provides C++11 support and, more interestingly, is written in C++11 and so can use things like r-value references internally for better performance (or to avoid needing ugly hacks to emulate them). Since it's written from scratch for modern platforms, it's optimised for the performance characteristics of modern platforms, while GNU libstdc++ is optimised for the hardware that was around 10-20 years ago.
By writing more GPL software, we are pushing companies to write more proprietary software that duplicates functionality and for which they will file for patents.
And you're encouraging the idea that Free Software is an all or nothing proposition. With the GPL, a company has the choice of releasing everything or releasing nothing. With permissively licensed code, they can easily contribute things that are not directly related to their core business and keep other things proprietary. Once they've done this, it's easier to encourage them to gradually expand the the set of things that they are releasing.
Personally, I would rather a company be encouraged to release some of its code back to the community than they be encouraged to keep everything proprietary.
I should probably add the disclaimer that I am the author of the wiki page that the original poster in this thread cited...
It's not a sense of entitlement, it's a desire to reach a situation where everyone receives the maximum benefit. Here's a concrete example for you:
I write a lot of Objective-C code that runs on a variety of platforms (developed on FreeBSD, but it runs on Linux, apparently someone uses some of it on Solaris, and so on). I want a decent Objective-C compiler. Apple also wants a decent Objective-C compiler, and they want to be able to reuse the parser in their (proprietary) IDE and a few other tools.
Apple was shipping GCC as their compiler, but the GPL meant that they couldn't use the parser for syntax highlighting or refactoring tools in their IDE without having to GPL the whole thing. So they started working on a new front end which they released under a BSD-like license and I contributed quite a few improvements and bug fixes. Apple got a few days worth of free work out of me, I got a few man-years of free work out of them. Both of us benefitted. They can keep their IDE proprietary, and I can use a high-quality Objective-C compiler on FreeBSD.
The GPL meant that they couldn't use the code as they wanted, so their only choice was to rewrite it completely. Note that this isn't limited to proprietary software: GPLv2 is incompatible with things like the Apache and Mozilla licenses, so if you want to use a library under one of these then you can't use GPLv2 code. GPLv3 comes with some patent licensing clauses that mean that a lot of companies won't let it in the door.
FreeBSD is okay on laptops, the current issue if video cards. nVidia still releases blob drivers for FreeBSD, but the latest Intel and AMD drivers rely on things like GEM/TTM/KMS that are Linux-specific. There is currently a FreeBSD Foundation-funded project underway to provide all of the kernel support that the Intel drivers need, but the AMD drivers are going to take a bit longer...
That's not quite the same. The tool sellers had a little risk, but not a huge return. You can sell spades to 1,000 prospectors, but the one who strikes gold will probably make a lot more than you. In contrast, users of Amazon's S3 pay Amazon more the more that they scale up. Amazon is not selling them something at a fixed price, it is selling them a service that takes some percentage of their income. If an S3 customer becomes successful and their revenue goes from $1,000 to $1,000,000 then Amazon's income also increases by a factor of a thousand.
That's the point of using open protocols. The service should not support the operating system, the service provider and the operating system provider should both support the same protocol. For example, if you have a WebDAV server running somewhere then pretty much any modern operating system can mount it.
In the '90s, every Windows user installed WinZIP (a few even paid for it!). Everyone distributed zip files and WinZIP was the tool for opening and creating them. It wasn't a sexy market, but it was a solution to a problem that a lot of people had, and it was the tool that everyone used (except warez d00dz, who preferred rar). The, Windows came with the ability to explore zip files as if they were normal folders. The need for WinZIP dropped from almost everyone to practically no one overnight. The same thing happened on the Mac with StuffIt - OS X can natively open a variety of archive formats, so there is no need for a third-party tool.
Fast forward a decade, and DropBox is in the same position in the cloud storage market that WinZIP occupied in its own market. Everyone who needs to share a couple of files with a friend or colleague uses it. But now operating systems and other services are coming with some cloud storage, so there's less need for a third-party service.
LENR is not cold fusion. LENR is a broad category and basically means 'stuff that is not high-energy fission / fusion.' It includes neutron capture (i.e. a neutron hits a nucleus, is absorbed, and no fission occurs) and radioactive decay. There are a lot of LENR generators. Some pacemakers contain betavoltaic generators that are powered by a small quantity of tritium. The Russians used to power lighthouses with radiothermal generators (RTFs) and there are three of them powering each of the Voyager spacecraft, with a rated lifespan of about 60 years each.
eCat sounds like they are claiming two low-energy reactions: a neutron capture followed by a decay. This is potentially feasible, but then good snake oil is always feasible...
"I thought someone was upset about not getting there check," said Laura Kelly, who took a friend to the office on Tuesday.
And this claims to be a news source? That standard of English is pretty poor even by Slashdot standards...
The McCarthy era also provides a lot of counterexamples to the argument 'I'm not doing anything I'm ashamed of, why should I care?' Consider the person who, during the Second World War was involved with a charity to send aid to parts of Russia recovering from the Nazi invasion. At the time, the USSR and the USA were allies. These people were involved in sending food and medical supplies to one of their allies in a time of war: surely nothing to be ashamed of? But then, just a little bit later, the USSR was the Evil Empire and anyone who supported it in any way was an evil communist and a traitor. The House Committee on Unamerican Activities would look at this charitable donation as evidence of communist sympathies and you could lose your job and be alienated from your friends.
Which is why, in my original post, I said that the government should be structuring laws to encourage innovative business models like this, rather than trying to prop up ones that have no long-term future. Creating software (or art) is difficult. Copying and distributing it is easier than it was and is getting easier all of the time. Any business model that depends on doing the difficult bit for free and then charging for the easy bit is doomed to failure in the long run.
Here's the obligatory car analogy: Imagine if a car company would give you a car for free and charge $20,000 to paint it for you. Now imagine if this was the established business model that all car companies used and there were laws in place saying that unpainted cars could not be used on the road and that only the car manufacturer was allowed to paint the cars that they made. Initially, car painting used expensive paints and required some complex techniques. Now, anyone can do it with a hundred dollars or so of equipment and paint. In a few years, drive-through car painting services are going to be possible costing under $20 for a new coat of paint, but the car industry is refusing to change their business model and insisting that the government impose strict distribution controls on all of the materials that can be used to make car paints.
That's more or less the situation that we're in with copyright. The established players are tied to a doomed business model and they'd rather break the rest of the economy than adapt.
No recent open source AMD ones either. The recent open source AMD and Intel 'X.org' drivers are so full of Linux kernel dependencies that it's difficult to port them. This is a shame, because a lot of smaller operating systems (e.g. Haiku) base their 3D support off FreeBSD's DRI port. There is currently work underway to support the stuff needed for the Intel drivers, but AMD ones are a bit further away. The nVidia blob drivers are the best supported by FreeBSD.
If anyone at AMD or Intel is reading this: please get your driver team to pay a bit of attention to portability...
I guess, but for normal desktop use is there really much to gain? These are 'desktop' distros/respins we're talking about here. I run ext4 on my main workstation and am happy.
ZFS is one of those things that you don't really appreciate until you've used it. Creating ZFS filesystems is about as hard as creating new directories, so with ZFS you generally create a lot of filesystems - they're dynamically sized, so the typical downside of this is not there.
Turning on compression or deduplication, or maybe encryption, for a particular filesystem is a single command. If you've got some really important data then you can tell it to store multiple copies on a single disk, so block-level errors are recoverable, not just detectable, even without RAID.
The most useful feature, however, is snapshots. It's trivial to set up a cron job that snapshots a filesystem every day, hour, or whatever. Ever deleted a file by mistake, or had a program error corrupt a document? With automatic snapshots, you can simply mount the old version of the filesystem and restore it. I think GNOME has a GUI for this (Time Slider or something) letting you just move a slider to go back to an earlier state of a filesystem.
It's also great for testing. Not sure if something is safe to run? Clone the filesystem, try it, and then destroy the clone and do it on the live fs. Or, if nothing else will be modifying the filesystem, just snapshot, run it, and roll back if it doesn't work.
On FreeBSD, ZFS integrates nicely with jails (on Solaris, s/jails/zones) so you can run untrusted programs in a jail by just cloning a jail that's set up for test systems and then throwing it away at the end.
Snapshots and clones in ZFS are cheap to create. It stores everything using reference counting and copy-on-write semantics, so all you need to do to create a clone is increment a reference count for a filesystem root. Modifications to either the clone or the original will create new copies of the files (they will anyway, because ZFS supports transactional I/O, so the FS is always in a consistent state).
One big thing you will notice is that the BSD teams are a bit less deprecation-happy than Linux developers. Over in Linux land, components seem to have two states: unfinished and deprecated. BSDs tend not to replace things that work, tend to favour incremental improvements over complete rewrites, and care a lot about interface stability. Most of the administrative stuff I learned when I first used FreeBSD a decade ago is still valid now - the implementations have changed a lot, but the tools still appear to act the same way. They also put a lot of effort into maintaining binary compatibility for the core system.
Most employers recognize you working-class-hero types are 90% garbage. Holding out for a proper solution would realistically mean it would never get done.
Bullshit, and probably an intentional troll that I've fallen for.
Most businesses do a cost-benefit analysis. Given the choice of doing a solution that kind-of works in two months and one that works well in two years, the first gives you 22 months of income from selling your products / services before the second is ready and costs a lot less. It's only industries like aerospace, where a product failure is very expensive that you have the luxury of doing things properly.