I'm not sure if "credit" is the word I'd use when describing Dell pre-loading Linux. I recently got one of their XPS 13 Developer Editions and it's unusable out of the box. It's literally not possible to type on it without spending a huge amount of time trying to fix the touchpad. If anything, buying one of these machines pre-loaded with Linux is probably a deterrent for a new user to ever try Linux again. It's a shame because I really wanted to like the machine.
You could probably do something like this with a proxy. Squid might even be up for the task already. Just have the proxy get all the content on the page (including ads) but have the proxy filter everything before it reaches your browser. You could even set it up in a VM that rolls itself back to a clean state periodically. The problem with doing this is that it would probably drastically increase latency. Waiting for the entire unfiltered page to load before a single bit appears on your screen isn't going to make for a pleasant web experience.
That math seems reasonable but, it doesn't change the fact that a company released an enormous amount of gas into the atmosphere for no other reason than incompetence. It's a small percentage of the overall pollution produced by the US but, generally, that pollution at least has some purpose other than, "Ooops". Ignoring or dismissing this as a minor incident just tips the risk/reward scale for corporations further towards "Fuck it. Who cares if it leaks".
That doesn't update you to 14.04.4, that installs the backported kernel and Xorg drivers. That's not necessary if all your hardware is already supported in vanilla 14.04. If you are already running 14.04.3, the upgrade process is transparent and will happen when you next run dist-upgrade or click the "install updates" button when it next nags you. The ".4" part of the version number has no real meaning beyond, "It has been about 6 months since we last incremented the version number so, let's do so and refresh the images so people are downloading the latest bits". Since the LTS versions have 5 years of support, not refreshing the download images means that, as time goes on, the originally packages are so out of date that you have to upgrade almost all of them immediately after installing. It's really just an arbitrary timestamp rather than what most people would consider an upgrade.
I wonder if this is the reason TP-Link has been moving away from Atheros based wireless gear. If you look at reviews on Amazon, TP-Link has been incrementing version numbers on some of their products and replacing the Atheros chip with chips that require binary blob firmware. As far as I know, Atheros is the only chipset that doesn't require a binary blob firmware and it's trivial to hack the kernel module so, dumping it for other chipsets might make sense (at least from their perspective) from a compliance standpoint.
Ubuntu still uses compiz for compositing (at least as of 14.04). The default settings don't allow for much configuration of compiz but, unity-tweak-tool allows you to tweak some properties of the handful of compiz modules that are enabled in Ubuntu. You can also install things like compiz-plugins and compizconfig-settings-manager and tweak things further. I haven't tried this because fiddling with compiz settings is often the kiss of death but, you should be able to turn on wobbly windows if that's your thing.
Also, thanks for the interview, Matthew. Good to see you're still involved in Ubuntu. Seems like all the old mods/admins from the Ubuntu forums (myself included) are no longer really involved with Ubuntu.
It depends on how you've setup your RAID0 array. If you are using mdraid, you can simply take the array offline, dd the contents of a failing disk onto a new disk, remove the old disk and bring the array back online (you can do this with a USB boot stick if you need to take the root filesystem offline). That's certainly more work than popping a failing disk out of a hotswap bay, screwing a new disk into the drive tray and pushing it back in. But, it's not that prohibitive.
Now, having said that, I certainly wouldn't build a RAID0 array out of a bunch of "green" desktop disks or out of bulk storage disks. I have a RAID0 array with 4 Intel 80GB SSDs and SMART says they have an online time of 4.3 years. They have incredible performance and never a hiccup. If I lost one of the disk controllers, the data could be restored in a few hours with a single rsync.
My point is that RAID0 has a place. It may not have a place in your setup but, it's not inherently flawed technology. It's a technology that is aimed at maximum performance with a bit more risk in downtime when compared to a single disk.
RAID0 is unsuitable for situations that require very high uptime but there is nothing inherently dangerous about storing real data on a RAID0 array. I know this gets said frequently but, RAID, at any level, isn't a backup. It's a reliability/performance feature. Even if you had configured these three disks as a triple mirrored RAID1, you would be insane to not run SMART monitoring tools on the disks and even more insane to not have good backups. I don't know if I've ever had a disk fail without plenty of warning from SMART monitoring so, for RAID0, you are mostly gaining some performance at the expense of more difficult disk replacements. That seems like a very acceptable tradeoff for something like a gaming machine.
You should be able to do wifi too if you are using something like Xen for virtualization. You can use PCI-passthrough on an Atheros based wifi card and the VM will see it as the real hardware. Then you just need to run hostapd in the VM and you are all set.
Even beyond the conflict of interest, the dealer doesn't actually provide a useful knowledge base to help you make an informed decision when buying a car. If you ask them *any* question whose answer isn't plainly stated on the sticker or in the meager sales brochure, you will get one of two answers: 1) A shrug and, "I dunno". or 2) A flat out lie. A couple hours of research on a car will make you the foremost expert in the building on that particular car. By a significant margin. Car sales people are the quientissential useless middle man. Maybe at one time they served a real purpose but, that time has long passed and now they just basically skim a bit of money off something they didn't create, don't know anything about and really don't even give a shit about.
You make good arguments and if I could, I'd mod you up even though I don't agree with you. One of the reasons that linux has been popular as a server OS is that you could easily distill it down to just the parts you needed. If you didn't like a particular component you could swap it out with a component more to your liking or even write a replacement. From a security standpoint, you were presenting a smaller attack surface by running a small number of heterogeneous components from different sources. From a maintainability standpoint you could easily read and understand the impact that updates might have. Sure, there were kludges and hacks and, if you wanted to argue that X-Windows is the most prolific kludge in the history of computing, I probably wouldn't argue with you.
The small, modular, "do what I want" nature of linux is basically the thing that makes linux, linux. If you wanted an opaque box that included everything but the kitchen sink, you could just use Windows. And that's what people hate about systemd: It's starting a trend to make linux more Windows-like and that is rightfully seen as a horrible direction to take things.
You might argue that I'm making an ideological argument but, linux has gained its popularity from sysadmins; not from developers or desktop users. Sysadmins value stability, simplicity and the ability to understand the system they are running. Systemd effectively removes all those features from the OS. Yes, it might make it easier for desktop environment developers to implement certain features but, the number of people that use linux as a desktop environment is laughably small compared to the number of servers running linux. So, basically, systemd is undermining the primary use-case of linux to appeal to an unlikely to ever grow user base (desktop users). Which is made even more bizarre in that it's primary developed by Red Hat: Practically the champion of linux as a mainstream server OS.
Basically, linux users don't want the OS to become a giant opaque monstrosity that can be prodded and observed but never really understood (like Windows).
That's a very level headed pro-systemd argument and, while I understand the sentiment, I can't agree with the approach that systemd has taken to accomplish this. In particular, letting an init system, strongly controlled by a single party, morph into an abstraction layer of the OS to such an extent that it's impossible to avoid it.
The problem with going to LFS is that it's a huge amount of work to maintain it. I ran an LFS based laptop for a few years and even wrote my own package manager to help maintain a level of sanity. LFS is an excellent learning experience and can be a great hobby but, sometimes you just want to type, "sudo apt-get install" instead of spending an afternoon building a tool.
The problem is that it's *not* a modern init system. In fact, I'm not really sure how to describe systemd apart from, "An overreaching solution to a problem that never actually existed". I don't think there is a single thing I can do with a systemd enabled system that I couldn't do in a 2008 version of Ubuntu. So, apart from complexity and a variation of vendor lockin, what has the linux world gained by moving to systemd?
This seems to indicate that the dealer has to provide the recall fix for free but doesn't have to pay for the damages that might have occurred because of the failure: http://www-odi.nhtsa.dot.gov/r.... It's possible that I'm not interpreting that correctly but, I've had recall work done on my FJ numerous times and never paid a penny for it. Presumably because the things that were being fixed hadn't caused any secondary damage.
I guess it's a matter of perspective. They've managed to conquer a small swath of barely ariable land, sell numerous ancient artifacts that they didn't discover and kill an infitesimally small percentage of westerners. And they did all of that using the technology of the "much more clever" westerners.
There is a simple explanation for this. After being lost on El Camino Real for hours and hundreds of miles, the car simply lost its will to live and was looking for a safe-ish place to park for the night.
I've never had the chance to use the Intel TBB stuff but, it looks like it's at least well thought out. The big thing with data flow programming is that it's very difficult to wrap your head around it. I've worked on a number of data flow projects and we've always built graphical tools to actually define the flow and then layout the underlying C/C++/Fortran/Assembly based on the graphs that we've visually created. Effectively, you create a visual programming language to control the flow, then use lower level languages to do the heavy lifting. Maybe TBB has that but, this (http://tensorflow.org/how_tos/graph_viz/index.md) seems like the typical kinds of things all data flow projects end up getting to. Once you go data flow, you realize you need a better editor, a more informative "compiler" and, especially, a better debugger.
It's often the case that if you can express your algorithms as directed acyclic graphs, you can get amazing parallelism out of them. Rather than painstakingly programming the algorithm to run in parallel using control flow constructs, you just define your algorithm as a graph, spin up a bunch of threads and tell all the threads to consume any node in the graph whose dependencies have already been computed. This type of thing started to become common in the late 90s with things like the LINPACK benchmarks. It was difficult to get the algorithm to scale well on high CPU count machines but, if you defined it as a directed acyclic graph and then built an algorithm to efficiently consume that graph, the scalability was shockingly good.
Even outside the AI aspects of the library, it looks cool in that it seems to provide a framework for defining data flow algorithms with the specific intent of reaching a high level of scalability. There have been tools to do this in the past but, they have frequently been clumsy internal tools and geared towards a specific set of algorithms. I've even seen someone heroically define the LINPACK benchmark as a data flow algorithm in SPARC assembly. This stuff seems really cool and fairly accessible.
Slashdot Mirror
I'm not sure if "credit" is the word I'd use when describing Dell pre-loading Linux. I recently got one of their XPS 13 Developer Editions and it's unusable out of the box. It's literally not possible to type on it without spending a huge amount of time trying to fix the touchpad. If anything, buying one of these machines pre-loaded with Linux is probably a deterrent for a new user to ever try Linux again. It's a shame because I really wanted to like the machine.
You could probably do something like this with a proxy. Squid might even be up for the task already. Just have the proxy get all the content on the page (including ads) but have the proxy filter everything before it reaches your browser. You could even set it up in a VM that rolls itself back to a clean state periodically. The problem with doing this is that it would probably drastically increase latency. Waiting for the entire unfiltered page to load before a single bit appears on your screen isn't going to make for a pleasant web experience.
I've been dreading my poop transplant for weeks.
Not if they saved more than $300M by storing this stuff in questionable ways.
That math seems reasonable but, it doesn't change the fact that a company released an enormous amount of gas into the atmosphere for no other reason than incompetence. It's a small percentage of the overall pollution produced by the US but, generally, that pollution at least has some purpose other than, "Ooops". Ignoring or dismissing this as a minor incident just tips the risk/reward scale for corporations further towards "Fuck it. Who cares if it leaks".
I personally wouldn't trust any of my servers on 16.04 until 2017. Let someone else beta test it.
My guess would be the fourth month of 2016...
15.10.4lyfe
Or at least the next 5 months.
That doesn't update you to 14.04.4, that installs the backported kernel and Xorg drivers. That's not necessary if all your hardware is already supported in vanilla 14.04. If you are already running 14.04.3, the upgrade process is transparent and will happen when you next run dist-upgrade or click the "install updates" button when it next nags you. The ".4" part of the version number has no real meaning beyond, "It has been about 6 months since we last incremented the version number so, let's do so and refresh the images so people are downloading the latest bits". Since the LTS versions have 5 years of support, not refreshing the download images means that, as time goes on, the originally packages are so out of date that you have to upgrade almost all of them immediately after installing. It's really just an arbitrary timestamp rather than what most people would consider an upgrade.
I wonder if this is the reason TP-Link has been moving away from Atheros based wireless gear. If you look at reviews on Amazon, TP-Link has been incrementing version numbers on some of their products and replacing the Atheros chip with chips that require binary blob firmware. As far as I know, Atheros is the only chipset that doesn't require a binary blob firmware and it's trivial to hack the kernel module so, dumping it for other chipsets might make sense (at least from their perspective) from a compliance standpoint.
Ubuntu still uses compiz for compositing (at least as of 14.04). The default settings don't allow for much configuration of compiz but, unity-tweak-tool allows you to tweak some properties of the handful of compiz modules that are enabled in Ubuntu. You can also install things like compiz-plugins and compizconfig-settings-manager and tweak things further. I haven't tried this because fiddling with compiz settings is often the kiss of death but, you should be able to turn on wobbly windows if that's your thing.
Also, thanks for the interview, Matthew. Good to see you're still involved in Ubuntu. Seems like all the old mods/admins from the Ubuntu forums (myself included) are no longer really involved with Ubuntu.
It depends on how you've setup your RAID0 array. If you are using mdraid, you can simply take the array offline, dd the contents of a failing disk onto a new disk, remove the old disk and bring the array back online (you can do this with a USB boot stick if you need to take the root filesystem offline). That's certainly more work than popping a failing disk out of a hotswap bay, screwing a new disk into the drive tray and pushing it back in. But, it's not that prohibitive.
Now, having said that, I certainly wouldn't build a RAID0 array out of a bunch of "green" desktop disks or out of bulk storage disks. I have a RAID0 array with 4 Intel 80GB SSDs and SMART says they have an online time of 4.3 years. They have incredible performance and never a hiccup. If I lost one of the disk controllers, the data could be restored in a few hours with a single rsync.
My point is that RAID0 has a place. It may not have a place in your setup but, it's not inherently flawed technology. It's a technology that is aimed at maximum performance with a bit more risk in downtime when compared to a single disk.
RAID0 is unsuitable for situations that require very high uptime but there is nothing inherently dangerous about storing real data on a RAID0 array. I know this gets said frequently but, RAID, at any level, isn't a backup. It's a reliability/performance feature. Even if you had configured these three disks as a triple mirrored RAID1, you would be insane to not run SMART monitoring tools on the disks and even more insane to not have good backups. I don't know if I've ever had a disk fail without plenty of warning from SMART monitoring so, for RAID0, you are mostly gaining some performance at the expense of more difficult disk replacements. That seems like a very acceptable tradeoff for something like a gaming machine.
You should be able to do wifi too if you are using something like Xen for virtualization. You can use PCI-passthrough on an Atheros based wifi card and the VM will see it as the real hardware. Then you just need to run hostapd in the VM and you are all set.
Even beyond the conflict of interest, the dealer doesn't actually provide a useful knowledge base to help you make an informed decision when buying a car. If you ask them *any* question whose answer isn't plainly stated on the sticker or in the meager sales brochure, you will get one of two answers: 1) A shrug and, "I dunno". or 2) A flat out lie. A couple hours of research on a car will make you the foremost expert in the building on that particular car. By a significant margin. Car sales people are the quientissential useless middle man. Maybe at one time they served a real purpose but, that time has long passed and now they just basically skim a bit of money off something they didn't create, don't know anything about and really don't even give a shit about.
You make good arguments and if I could, I'd mod you up even though I don't agree with you. One of the reasons that linux has been popular as a server OS is that you could easily distill it down to just the parts you needed. If you didn't like a particular component you could swap it out with a component more to your liking or even write a replacement. From a security standpoint, you were presenting a smaller attack surface by running a small number of heterogeneous components from different sources. From a maintainability standpoint you could easily read and understand the impact that updates might have. Sure, there were kludges and hacks and, if you wanted to argue that X-Windows is the most prolific kludge in the history of computing, I probably wouldn't argue with you.
The small, modular, "do what I want" nature of linux is basically the thing that makes linux, linux. If you wanted an opaque box that included everything but the kitchen sink, you could just use Windows. And that's what people hate about systemd: It's starting a trend to make linux more Windows-like and that is rightfully seen as a horrible direction to take things.
You might argue that I'm making an ideological argument but, linux has gained its popularity from sysadmins; not from developers or desktop users. Sysadmins value stability, simplicity and the ability to understand the system they are running. Systemd effectively removes all those features from the OS. Yes, it might make it easier for desktop environment developers to implement certain features but, the number of people that use linux as a desktop environment is laughably small compared to the number of servers running linux. So, basically, systemd is undermining the primary use-case of linux to appeal to an unlikely to ever grow user base (desktop users). Which is made even more bizarre in that it's primary developed by Red Hat: Practically the champion of linux as a mainstream server OS.
Basically, linux users don't want the OS to become a giant opaque monstrosity that can be prodded and observed but never really understood (like Windows).
That's a very level headed pro-systemd argument and, while I understand the sentiment, I can't agree with the approach that systemd has taken to accomplish this. In particular, letting an init system, strongly controlled by a single party, morph into an abstraction layer of the OS to such an extent that it's impossible to avoid it.
The problem with going to LFS is that it's a huge amount of work to maintain it. I ran an LFS based laptop for a few years and even wrote my own package manager to help maintain a level of sanity. LFS is an excellent learning experience and can be a great hobby but, sometimes you just want to type, "sudo apt-get install" instead of spending an afternoon building a tool.
The problem is that it's *not* a modern init system. In fact, I'm not really sure how to describe systemd apart from, "An overreaching solution to a problem that never actually existed". I don't think there is a single thing I can do with a systemd enabled system that I couldn't do in a 2008 version of Ubuntu. So, apart from complexity and a variation of vendor lockin, what has the linux world gained by moving to systemd?
This seems to indicate that the dealer has to provide the recall fix for free but doesn't have to pay for the damages that might have occurred because of the failure: http://www-odi.nhtsa.dot.gov/r.... It's possible that I'm not interpreting that correctly but, I've had recall work done on my FJ numerous times and never paid a penny for it. Presumably because the things that were being fixed hadn't caused any secondary damage.
I guess it's a matter of perspective. They've managed to conquer a small swath of barely ariable land, sell numerous ancient artifacts that they didn't discover and kill an infitesimally small percentage of westerners. And they did all of that using the technology of the "much more clever" westerners.
This seems like a great plot for the next Indiana Jones movie. Maybe they could even have a Spock cameo.
There is a simple explanation for this. After being lost on El Camino Real for hours and hundreds of miles, the car simply lost its will to live and was looking for a safe-ish place to park for the night.
I've never had the chance to use the Intel TBB stuff but, it looks like it's at least well thought out. The big thing with data flow programming is that it's very difficult to wrap your head around it. I've worked on a number of data flow projects and we've always built graphical tools to actually define the flow and then layout the underlying C/C++/Fortran/Assembly based on the graphs that we've visually created. Effectively, you create a visual programming language to control the flow, then use lower level languages to do the heavy lifting. Maybe TBB has that but, this (http://tensorflow.org/how_tos/graph_viz/index.md) seems like the typical kinds of things all data flow projects end up getting to. Once you go data flow, you realize you need a better editor, a more informative "compiler" and, especially, a better debugger.
It's often the case that if you can express your algorithms as directed acyclic graphs, you can get amazing parallelism out of them. Rather than painstakingly programming the algorithm to run in parallel using control flow constructs, you just define your algorithm as a graph, spin up a bunch of threads and tell all the threads to consume any node in the graph whose dependencies have already been computed. This type of thing started to become common in the late 90s with things like the LINPACK benchmarks. It was difficult to get the algorithm to scale well on high CPU count machines but, if you defined it as a directed acyclic graph and then built an algorithm to efficiently consume that graph, the scalability was shockingly good.
Even outside the AI aspects of the library, it looks cool in that it seems to provide a framework for defining data flow algorithms with the specific intent of reaching a high level of scalability. There have been tools to do this in the past but, they have frequently been clumsy internal tools and geared towards a specific set of algorithms. I've even seen someone heroically define the LINPACK benchmark as a data flow algorithm in SPARC assembly. This stuff seems really cool and fairly accessible.