I would bet that 2.6.x still has a significant install base under the names RHEL5 & 6, centos 5 & 6, oracle linux 5 & 6... And aside from that middle brand, these are people who are probably paying for vendor support, which makes them more equal than other linux users.
That takes me back. When did we get automatic PCI IRQ steering, Windows 95 (20 something years ago)? I feel like this stopped being a problem when ISA went away.
It breaks fewer people's shit at once if there's a bug they didn't catch. It's like beta testing a new feature with a small group before deploying it to everyone. It's prudent.
It'd be nice if this proper OS existed at the present time because I'm not going back to Amiga despite its lack of viruses. I'm reading between the lines here, but I infer you are setting up Linux or a BSD variant as this hypothetical proper OS, all of which have their fair share of vulnerabilities and are even harder for non-technical end users to configure correctly to avoid problems.
Sometimes you don't want to put a 450 kg warhead through somebody's window when an 8 kg warhead will do.
Sometimes you don't know how many targets there are until you're near the target.
Sometimes you need to use additional missiles if the first wasn't sufficient and can't afford the non-trivial flight time for a second launch.
Sometimes you want to go home without blowing things up and without wasting 1.6M USD.
There are advantages to having a reusable launch platform in the area, whether that be a UAV or a strike fighter.
Nevermind, it's not clear from the summary, but all of the articles mention this. Yes there is still licensing, no the rules are not as strenuous as a full pilot's license (no medical, etc).
FPV flight is still dead without a waiver. Interestingly, you can fly above 400' as long as you are within 400' of a structure (eg, for remote visual inspection of tall buildings).
Think of it more as Amazon trying to encourage the development of automated photo morphing technology. In a decade, we may have some awesome algorithms to obviate those photo editor people... what's the word... Photographers.
I'm glad you're able to repair defects that only occur on hardware you don't own, that you can't reproduce, and can't validate as fixed for hardware/firmware with no vendor support, having no published specification, and will be obsoleted in only a few years. There are hundreds of different platforms to support when nobody follows the spec. Most people consider that somewhere between "frustratingly difficult" and "damn near impossible."
[..]constantly updated, but also a limited number of hardware variants and software configurations.[..]
Are we talking about the same Android? You seem to have enumerated where android is the weakest; poor vendor update frequency, many varied hardware platforms, a plethora of vendor or user customized software configurations.
Argument failure on my part. After reading subsequent posts you made clarifying your position, no, I don't see any advantage for the common consumer to go out and replace all their old things with new ones. Someone like me might like that I can use my phone to one-click reconfigure my tv and receiver to play video games or select a movie on netflix and have the tv switch inputs to whatever and just start playing it--heck I can do this now, but IoT should make it much easier. Granted there are a crapload of privacy concerns exactly like you and other commenters have cited that are of serious concern. That stated, given the low incremental cost of enabling IoT on a device, it's pretty damn likely to end up in all products whether you like it or not.
I think you're going to wake up one morning and realize the internet-of-things revolution happened quietly around you. Either that or you're going to get dragged kicking and screaming into an internet-of-things world much like the textile workers of the early 1800s who opposed industrialization.
For the most part, the necessary tech artifacts you're talking about already exist. You can already order a mesh-routed, IPv6 aware radio IC for pretty cheap (6LoWPAN, example part by TI). It's been 4 years since NXP Semi demo'd occupancy-aware lighting modules. For me at least, intelligent lighting is a big deal because lighting costs are the third highest contributor to my electric bill.
The hardest parts, in my opinion, are pushing for standardization of interfaces to keep complexity and cost down, and ever-important though higher-visibility now, security and access control. There are already significant working groups dedicated to these tasks, for example, the goog/nest, ARM, samsung, et.al. in the Thread group. But there are a ton of different and incompatible ways to do the same thing; ANT+, bluetooth LE, zigbee, and 6lowpan are just the low power ones I can think of off the top of my head. And that's just the physical through network OSI layers, it doesn't begin to address announcement of features (zeroconf, etc.) to each other or standardized interface presentation to the user (????).
So where are the products? Well, Nest gen2 thermostat is IoT-enabled. Fitbit monitors all wirelessly update your stats and profile. Apple's [i]watch and the moto360 smart watch are both network-aware. Even companies outside of the consumer electronics sphere are getting invested, like Chevorlet's automotive lte/wifi.
Granted, these aren't the groundbreaking, for-every-person products you're talking about, but the tech infrastructure is coming into its own. Product development takes time and age is only going to make the baseline models cheaper, more capable, more standard, and more prevalent. There's a lot of work to be done yet, but given the number of people and companies invested in IoT consumer electronics industry-wide, it's hard to imagine a world where everyone simply gave up on the tech instead of working out the problems.
I believe you need the gap to be smaller than the half-wavelength + some physics about energy absorption. With that caveat, I figure your half-inch chicken wire would be effective to 12GHz or so. More than enough to destroy cellular service in your home.
A services manager, actually. It starts and stops services on the system, and if they go down, it optionally restarts them. The fact that many services need to start when the system starts is somewhat incidental to the purpose of systemD.
The task you have described seems like something that could be sanely done outside pid1 without worrying that a defect in its significantly larger-than-average-init codebase could cause the entire system to reboot.
Though I guess some might consider that a feature; at least you know you'll never be running without systemd.
Seems like there is some research out there about this sort of thing already, found this in one try: Digital Communication over
Speech Compressed Channel (Sverrisson 2008). I think the main problem would be that the baseband processor generally has direct control of the microphone, so you'd have to do some trickery, or use a phone where this simply isn't true.
It can't unless it is sold in volume. Quality software takes time (read: money) to write, support, and bugfix. If you want anything with a limited market segment, by its very nature it has to be expensive to be of reasonable (and useful) quality or you are relying on the generosity of a not-for-profit software development organization.
But such a constraint makes the comparison apples to apples. To further stretch the illusion of comparability consider an i7-4700MQ or similar. Same market segment (you find them in MS Surface Pros, that's a tablet, right?) but without the power constraint, at 45W that thing blows away pretty much any chip in either ARM or Atom lines. i7, atom, and arm are all different optimizations of price, performance, power. From what I gather, in the mobile segment, performance/power is pretty much king.
Racked at the house...
Dell C6100, 4x { 2x L5639, 32GB ram }
Dell C1100, 2x L5639, 48GB ram
Dell Powerconnect 5324 with a permanent fan error because I unplugged it, the noisy bastard.
Ubiquiti ERL-3
Maybe half full of SATAs, most of which are spun down. Further sliced into VMs because I like to play around with KVM/ESXi. Mostly used for ADC, media serving, local backup, test build environments, autodeployment script tests, etc. It'll draw 6-8A @110V easy with everything spinning max load, but it usually idles around 1.2-2A as I only wake 3 of the C6100 sleds on-demand. Config exactly mirrors my colo, which pays for both, but is not my job.
Workstation's notable components are the G530, GTX460, a cheap-as-it-comes asus MB, and 3x displays.
Half a dozen or so ARM SBCs (rpi, udoo, beaglexM, etc) doing menial things like RTP audio endpoints, ethernet-attached GPIO, openelec.
That sounds amazingly convoluted and backward, but I don't doubt that's how it works.
However, if Qualcomm sells Samsung a part without licenses and separately licenses/sells/supports the driver software without licenses (I am dangerously assuming Samsung didn't write their own), conditionally saying the driver cannot be used with the part because that would be in violation of the patent, then Samsung uses them together and distributes it, why would not Qualcomm go to town on Samsung in the spirit of cover-your-ass? They'd have to be in collusion to commit patent fraud. But if Qualcomm licensed the driver to Samsung for use with the part, the two together seem like patent exhaustion would have to apply, unless, like you said, Samsung assumed responsibility for paying Qualcomm's patent royalties and fees. Samsung wouldn't be using the patent directly, Samsung would be using a part that uses the patent.
I guess fundamentally I am misapprehending how you can somehow sell a product or combination of products as fit for purpose that are covered by patents and yet not assume patent license liability. Thanks for your insight on how this whole thing works.
Ok, I think I now see where you are coming from here, as well as AC below you. Since Qualcomm didn't have a license, Samsung couldn't have triggered patent exhaustion because Qualcomm never had a license to exhaust. It's then open to court interpretation whether or not Samsung should be liable for use of the patent.
The difference between this case and Quanta v. LG (2008) is that Qualcomm didn't have a patent license to sell their part. Even if Samsung is not practicing the patent itself, they might still be liable. This is then the part that confuses me: if Qualcomm acquires a license for historical sales, wouldn't Samsung again be protected from infringement?
Slashdot Mirror
15.04, and the battle was limited to the online reviews. The actor change went largely unnoticed by most viewers.
I would bet that 2.6.x still has a significant install base under the names RHEL5 & 6, centos 5 & 6, oracle linux 5 & 6... And aside from that middle brand, these are people who are probably paying for vendor support, which makes them more equal than other linux users.
Hire actual QA. Showstopping bugs prevent me from getting shit done. Looking at you, Windows Insider program.
That takes me back. When did we get automatic PCI IRQ steering, Windows 95 (20 something years ago)? I feel like this stopped being a problem when ISA went away.
It breaks fewer people's shit at once if there's a bug they didn't catch. It's like beta testing a new feature with a small group before deploying it to everyone. It's prudent.
We're just lucky it's not a ring -3 antivirus coprocessor embedded in the northbridge.
It'd be nice if this proper OS existed at the present time because I'm not going back to Amiga despite its lack of viruses. I'm reading between the lines here, but I infer you are setting up Linux or a BSD variant as this hypothetical proper OS, all of which have their fair share of vulnerabilities and are even harder for non-technical end users to configure correctly to avoid problems.
Sometimes you don't want to put a 450 kg warhead through somebody's window when an 8 kg warhead will do.
Sometimes you don't know how many targets there are until you're near the target.
Sometimes you need to use additional missiles if the first wasn't sufficient and can't afford the non-trivial flight time for a second launch.
Sometimes you want to go home without blowing things up and without wasting 1.6M USD.
There are advantages to having a reusable launch platform in the area, whether that be a UAV or a strike fighter.
Nevermind, it's not clear from the summary, but all of the articles mention this. Yes there is still licensing, no the rules are not as strenuous as a full pilot's license (no medical, etc).
FPV flight is still dead without a waiver. Interestingly, you can fly above 400' as long as you are within 400' of a structure (eg, for remote visual inspection of tall buildings).
http://www.faa.gov/uas/media/P...
Is that not the point of the remote pilot airman certificate?
Think of it more as Amazon trying to encourage the development of automated photo morphing technology. In a decade, we may have some awesome algorithms to obviate those photo editor people... what's the word... Photographers.
I'm glad you're able to repair defects that only occur on hardware you don't own, that you can't reproduce, and can't validate as fixed for hardware/firmware with no vendor support, having no published specification, and will be obsoleted in only a few years. There are hundreds of different platforms to support when nobody follows the spec. Most people consider that somewhere between "frustratingly difficult" and "damn near impossible."
[..]constantly updated, but also a limited number of hardware variants and software configurations.[..]
Are we talking about the same Android? You seem to have enumerated where android is the weakest; poor vendor update frequency, many varied hardware platforms, a plethora of vendor or user customized software configurations.
Argument failure on my part. After reading subsequent posts you made clarifying your position, no, I don't see any advantage for the common consumer to go out and replace all their old things with new ones. Someone like me might like that I can use my phone to one-click reconfigure my tv and receiver to play video games or select a movie on netflix and have the tv switch inputs to whatever and just start playing it--heck I can do this now, but IoT should make it much easier. Granted there are a crapload of privacy concerns exactly like you and other commenters have cited that are of serious concern. That stated, given the low incremental cost of enabling IoT on a device, it's pretty damn likely to end up in all products whether you like it or not.
I think you're going to wake up one morning and realize the internet-of-things revolution happened quietly around you. Either that or you're going to get dragged kicking and screaming into an internet-of-things world much like the textile workers of the early 1800s who opposed industrialization.
For the most part, the necessary tech artifacts you're talking about already exist. You can already order a mesh-routed, IPv6 aware radio IC for pretty cheap (6LoWPAN, example part by TI). It's been 4 years since NXP Semi demo'd occupancy-aware lighting modules. For me at least, intelligent lighting is a big deal because lighting costs are the third highest contributor to my electric bill.
The hardest parts, in my opinion, are pushing for standardization of interfaces to keep complexity and cost down, and ever-important though higher-visibility now, security and access control. There are already significant working groups dedicated to these tasks, for example, the goog/nest, ARM, samsung, et.al. in the Thread group. But there are a ton of different and incompatible ways to do the same thing; ANT+, bluetooth LE, zigbee, and 6lowpan are just the low power ones I can think of off the top of my head. And that's just the physical through network OSI layers, it doesn't begin to address announcement of features (zeroconf, etc.) to each other or standardized interface presentation to the user (????).
So where are the products? Well, Nest gen2 thermostat is IoT-enabled. Fitbit monitors all wirelessly update your stats and profile. Apple's [i]watch and the moto360 smart watch are both network-aware. Even companies outside of the consumer electronics sphere are getting invested, like Chevorlet's automotive lte/wifi.
Granted, these aren't the groundbreaking, for-every-person products you're talking about, but the tech infrastructure is coming into its own. Product development takes time and age is only going to make the baseline models cheaper, more capable, more standard, and more prevalent. There's a lot of work to be done yet, but given the number of people and companies invested in IoT consumer electronics industry-wide, it's hard to imagine a world where everyone simply gave up on the tech instead of working out the problems.
I believe you need the gap to be smaller than the half-wavelength + some physics about energy absorption. With that caveat, I figure your half-inch chicken wire would be effective to 12GHz or so. More than enough to destroy cellular service in your home.
A services manager, actually. It starts and stops services on the system, and if they go down, it optionally restarts them. The fact that many services need to start when the system starts is somewhat incidental to the purpose of systemD.
The task you have described seems like something that could be sanely done outside pid1 without worrying that a defect in its significantly larger-than-average-init codebase could cause the entire system to reboot.
Though I guess some might consider that a feature; at least you know you'll never be running without systemd.
Seems like there is some research out there about this sort of thing already, found this in one try: Digital Communication over Speech Compressed Channel (Sverrisson 2008). I think the main problem would be that the baseband processor generally has direct control of the microphone, so you'd have to do some trickery, or use a phone where this simply isn't true.
Hi, it looks like you're trying to edit a document. Would you like to turn autocorrect on?
Yes | Of course!
------
(X_X) Sorry, the application Life Support has ended abnormally! Dicarbon Monoxide synthesis failed.
Ignore | Retry | Fail
------
(X_X) Sorry, the application Send Error Report has ended abnormally! Could not connect to report server.
Ignore | Retry | Fail
------
Feb 28 05:05:08 lifesupport.mars kernel: Fatal trap 12: clippy runtime error while in kernel mode
Feb 28 05:05:08 lifesupport.mars kernel: cpuid = 0; apic id = 00
Feb 28 05:05:08 lifesupport.mars kernel: panic: user error, replace user, then press any key.
It can't unless it is sold in volume. Quality software takes time (read: money) to write, support, and bugfix. If you want anything with a limited market segment, by its very nature it has to be expensive to be of reasonable (and useful) quality or you are relying on the generosity of a not-for-profit software development organization.
But such a constraint makes the comparison apples to apples. To further stretch the illusion of comparability consider an i7-4700MQ or similar. Same market segment (you find them in MS Surface Pros, that's a tablet, right?) but without the power constraint, at 45W that thing blows away pretty much any chip in either ARM or Atom lines. i7, atom, and arm are all different optimizations of price, performance, power. From what I gather, in the mobile segment, performance/power is pretty much king.
Require OEMs to have >80% of devices sold in the last 2 years capable of running the most recent version of Android within 3 months of release.
Racked at the house...
Dell C6100, 4x { 2x L5639, 32GB ram }
Dell C1100, 2x L5639, 48GB ram
Dell Powerconnect 5324 with a permanent fan error because I unplugged it, the noisy bastard.
Ubiquiti ERL-3
Maybe half full of SATAs, most of which are spun down. Further sliced into VMs because I like to play around with KVM/ESXi. Mostly used for ADC, media serving, local backup, test build environments, autodeployment script tests, etc. It'll draw 6-8A @110V easy with everything spinning max load, but it usually idles around 1.2-2A as I only wake 3 of the C6100 sleds on-demand. Config exactly mirrors my colo, which pays for both, but is not my job.
Workstation's notable components are the G530, GTX460, a cheap-as-it-comes asus MB, and 3x displays.
Half a dozen or so ARM SBCs (rpi, udoo, beaglexM, etc) doing menial things like RTP audio endpoints, ethernet-attached GPIO, openelec.
That sounds amazingly convoluted and backward, but I don't doubt that's how it works.
However, if Qualcomm sells Samsung a part without licenses and separately licenses/sells/supports the driver software without licenses (I am dangerously assuming Samsung didn't write their own), conditionally saying the driver cannot be used with the part because that would be in violation of the patent, then Samsung uses them together and distributes it, why would not Qualcomm go to town on Samsung in the spirit of cover-your-ass? They'd have to be in collusion to commit patent fraud. But if Qualcomm licensed the driver to Samsung for use with the part, the two together seem like patent exhaustion would have to apply, unless, like you said, Samsung assumed responsibility for paying Qualcomm's patent royalties and fees. Samsung wouldn't be using the patent directly, Samsung would be using a part that uses the patent.
I guess fundamentally I am misapprehending how you can somehow sell a product or combination of products as fit for purpose that are covered by patents and yet not assume patent license liability. Thanks for your insight on how this whole thing works.
Ok, I think I now see where you are coming from here, as well as AC below you. Since Qualcomm didn't have a license, Samsung couldn't have triggered patent exhaustion because Qualcomm never had a license to exhaust. It's then open to court interpretation whether or not Samsung should be liable for use of the patent.
The difference between this case and Quanta v. LG (2008) is that Qualcomm didn't have a patent license to sell their part. Even if Samsung is not practicing the patent itself, they might still be liable. This is then the part that confuses me: if Qualcomm acquires a license for historical sales, wouldn't Samsung again be protected from infringement?
Thank you all for straightening out my confusion.