Because they know that people don't always use the chargers that came with their devices. People buy extras so they can have one at home and one at work. They borrow chargers from friends. Sometimes, they even plug their phones into their computers to charge.
If you plug a devices that was designed around the USB Power Delivery spec into a charger that was designed around a proprietary rapid charging standard, (or vice versa) the two devices aren't going to understand each-other correctly during the process of negotiating charge voltage, current limiting, and which data lines (if any) to use to supplement charge current.
It would REALLY suck your USB standard phone signaled the charger that it wants 5V@3A and the charger, which uses a proprietary charge protocol, misunderstood the message and not only upped VBUS to 20V, but put 20V across all of the data pairs as well.
If that were to happen and the phone were to be irreparably damaged, the blame is going to get spread around between the charger and phone manufacturers. And some people are going to look at the situation and switch to iPhones because "at least they don't have this problem."
If using SVN directly doesn't fit your needs -- if you REALLY want the transparency of a shared filesystem (as opposed to explicitly saying "synchronize the contents of this directory with the image on the server" ) WebDAV builds that on top of SVN. And if you want access controls, Apache's mod_auth provides them. Encryption? mod_ssl.
Depending on the regulations attached to your specific industry and how your company chooses to cope with them, "being able to maintain the application" may not be sufficient. If something goes sufficiently pear-shaped to get a government agency involved, they may demand that you be able to produce not just the source code used to create any given release, but the combined libraries, toolchains, etc.
Hell, you *MAY* even be required to completely and faithfully recreate your entire development environment as it was on the date of sign-off. Only really feasible way, imho, to ensure that you can comply with that sort of a request is if you were to do all of your development inside a VM and take a snapshot when each release is blessed. (or at any other milestone)
Admittedly, a DIY USB-connected solution will likely compromise the thermal insulation and waterproofing of the safe to some degree... But COTS USB-connected fire safes *DO* exist.
Clearly, you never read the EULA, or even the Warranty statement.
Microsoft only promises that it will work as intended for the first 90 days after it's installed. After 90 days, if Microsoft decides to tell you to piss off, you're SOL, because the software is presented to you AS-IS.
During the warranty period, if you have a problem, Microsoft will, AT THEIR SOLE DISCRETION, either refund the money you paid for the software (if you actually paid anything for it. If it came preinstalled on your computer, you paid nothing for the software - the computer maker did. You have to talk to them) or they can choose to fix the problem.
If you're outside of the warranty period and you don't have an active support contract, Microsoft doesn't have to care about your problems at all.
Did you know that Intel's chipsets include a very respectable ethernet controller? Have for a long time. Most motherboard manufacturers don't use them, though. For some reason, they'd rather bolt a suck-tastic Realtek controller onto one of the PCIe lanes, instead.
Buying Intel-made boards is about the only way to get one that uses the on-chipset controller.... Unless you're going with an AMD CPU.
The way those tools work is that they write a customized firmware image onto the controller. (or an EEPROM, or the start of the flash) This way, if you don't need the thing to impersonate a CDROM, that code doesn't get loaded onto the chip. Specifics about partition sizes, read-only settings, etc, get tacked onto the end of the appropriate image as a data block.
If the chip manufacturer released a firmware update to address a bug in a previous release, the same tools can be used to install the firmware updates. You just have to replace the packaged images.
But you don't HAVE to use the bundled firmware images. A little legwork (or disassembly of the bundled firmwares) will yield all you need to know to write your own firmware for the thing that does whatever you want it to. Frequently, like the MV6208, the controller is built around an 8051-derivative. ( ref: http://www.belinking.com/downl... ) knowing that, you can write your own custom firmware that enumerates as a second keyboard to try and run commands. Or whatever else you want to make it do.
A typical USB stick or a webcam don't have hardware to permit firmware upgrades, even though the silicon inside could be theoretically upgradable.
How uninformed you are!
https://forums.hak5.org/index.php?/topic/8630-collection-of-production-tools-for-usb-devices/ is a discussion of "production tools" for USB flash drives.
These tools are specific to the controller in the flashdrive (chipsbank, micov, etc) and allow you to do things like change what size the drive reports itself as, load files onto the thing and make it behave as a read-only flash drive, load files on and make it behave as a USB CD/DVD-ROM drive with a disk preloaded, make it behave as a single flashdrive with multiple partitions, make it come up on the USB bus as a compound device consisting of any combination of the above.
My company uses these sorts of tools to distribute software on read-only flashdrives.
That's why it's important to actually read what they wrote instead of just stopping at the first "red flag" you come to.
Why flexible funding?
We choose flexible funding because we want to give people a chance to contribute to the software as early as possible. The hardware part is already done and we have sold units to existing customers who were very happy about it. Specially for this campaign we made a new revision ready for mass production so we can sell it at an even better price than we already had in our shop:
https://dptechnics.com/shop/?q...
They already have finalized hardware in production. They're not trying to fund hardware development and production. They've already done that. They're using indiegogo as an advertising channel and as a secondary storefront.
Most vehicles (if not all) being marketed for consumer road use have power steering. The standard (in the USA, if not globally) is to use hydraulics to help you move the wheels back and forth as you steer.
Those two models of Audi use electric motors to provide power assist, instead. That makes it MUCH easier to interface the control system.
The entry for "Alpha Particles" was updated from "Harmless." to "Mostly Harmless." quite some time ago. Because it is... AS LONG AS the emitter is *OUTSIDE* the body.
An alpha particle is going to steal electrons from the first molecule it comes in contact with, and become a helium atom. If you're exposed to alpha radiation from the outside, it's going to hit and react with the layer of already dead skin cells called the epidermis.
So yes, as long as you don't swallow, inhale, inject, or otherwise insert the alpha-emitting radioisotope, you're probably going to be just fine.
The fact that Google Play is run by an American company is not the issue.
Whether or not your app is available to be downloaded in the US is. Because you're importing your app into the US to be used by Americans.
But that's a side issue. EVEN BY AUSTRALIA'S STANDARDSyour app likely qualifies as a medical device. If you're not already registered with the Ministry of Health as a medical device manufacturer, I would highly recommend contacting someone to confirm with them whether your app should be regulated under Australian law, and whether you're breaking the law by distributing it (or allowing it to be distributed) in Australia without registration.
And then do the same thing with every other country your app is downloadable in. Because every country's regulations may be somewhat different.
For the purposes of this document, we refer to devices that contain one or more software components, parts, or accessories, or are composed solely of software as “software devices,” including:
firmware and other means for software-based control of medical devices
stand-alone software applications
software intended for installation in general-purpose computers
dedicated hardware/software medical devices.
accessories to medical devices when those accessories contain or are composed of software.
This guidance applies to software devices regardless of the means by which the software is delivered to the end user, whether factory-installed, installed by a third-party vendor, or field-installed or -upgraded.
So, yes, apps with a medical purpose are medical devices, just like any other piece of software.
Which means they *ARE* subject to the "Obamacare Tax" -- Which is *NOT* a "sales tax" to be paid by the consumer. It's an "income tax" to be paid by the manufacturer / developer.
This also means that if your app is categorized as a medical device, you (the developer) have to register with the FDA as a device manufacturer, which costs a couple thousand dollars a year, and means that every few years, the FDA sends someone out to review your quality control system, which includes your testing methodologies, what complaints you've received and how you've handled them, how you document your development process, etc.
AND what your software does determines what kind of medical device the FDA calls it. And the kind of medical device determines whether you are required to get the FDA's permission before you distribute it. (even if you distribute it for free) And yes, applying for that permission costs money, whether it's approved or not.
And, by the way: Each country makes its own rules about what makes a medical device and what you're required to do to be able to legally distribute it in that country. And in most countries that includes software.
I can see the argument that if you're limited in any way as to what you can do with your connection then it's not strictly neutral. I disagree with it completely, especially if the connection was sold under a "residential, not publicly accessible" contract. If this were about what content I could access via that connection, or how traffic from different providers / protocols is prioritized, THAT would be a neutrality issue.
If your connection is behind a NAT (carrier grade or otherwise) where you're sharing an IP with multiple other users, that's going to prevent you from being able to run a server that can accept connections from the outside world. -- unless your ISP adds rules to their router to ensure that certain ports on your connection are always available to the outside world. And if you want access to the standard ports (80, 53, 443, 25, 22, etc) they have to ensure that "your IP" is unique, at least among the subset of customers that want that ability.
Carrier grade NAT is only necessary because of widespread refusal (including among carriers) to adopt IPv6. But even without NAT, I still wouldn't have a problem with the ISP saying you can't run a server on a residential connection. Because IP space isn't the only limited resource in play.
The difference here is the guy who went to talk to the police on his own (ie voluntarily) vs being arrested (ie unwillingly).
Actually, the guy DIDN'T go to the police on his own. The police came to his house and started asking him questions, then they brought him to the station.
The differences between what happened and "an arrest" are that he was not mirandized and (presumably) was not handcuffed. It's still possible that the officers led him to believe he didn't have much choice in the matter.
Slashdot Mirror
Because they know that people don't always use the chargers that came with their devices. People buy extras so they can have one at home and one at work. They borrow chargers from friends. Sometimes, they even plug their phones into their computers to charge.
If you plug a devices that was designed around the USB Power Delivery spec into a charger that was designed around a proprietary rapid charging standard, (or vice versa) the two devices aren't going to understand each-other correctly during the process of negotiating charge voltage, current limiting, and which data lines (if any) to use to supplement charge current.
It would REALLY suck your USB standard phone signaled the charger that it wants 5V@3A and the charger, which uses a proprietary charge protocol, misunderstood the message and not only upped VBUS to 20V, but put 20V across all of the data pairs as well.
If that were to happen and the phone were to be irreparably damaged, the blame is going to get spread around between the charger and phone manufacturers. And some people are going to look at the situation and switch to iPhones because "at least they don't have this problem."
I agree with this AC.
If using SVN directly doesn't fit your needs -- if you REALLY want the transparency of a shared filesystem (as opposed to explicitly saying "synchronize the contents of this directory with the image on the server" ) WebDAV builds that on top of SVN. And if you want access controls, Apache's mod_auth provides them. Encryption? mod_ssl.
Depending on the regulations attached to your specific industry and how your company chooses to cope with them, "being able to maintain the application" may not be sufficient. If something goes sufficiently pear-shaped to get a government agency involved, they may demand that you be able to produce not just the source code used to create any given release, but the combined libraries, toolchains, etc.
Hell, you *MAY* even be required to completely and faithfully recreate your entire development environment as it was on the date of sign-off. Only really feasible way, imho, to ensure that you can comply with that sort of a request is if you were to do all of your development inside a VM and take a snapshot when each release is blessed. (or at any other milestone)
You (and other commenters) laugh at this idea,
Admittedly, a DIY USB-connected solution will likely compromise the thermal insulation and waterproofing of the safe to some degree... But COTS USB-connected fire safes *DO* exist.
For one example: http://www.sentrysafe.com/Prod...
Looking at the incident strictly from the standpoint of the PR fallout that NASA received as a result, which do you think would have been worse?
They HAD that ability, but they pissed it away. NASA refused to listen to engineers and the contractors who were telling them that the O-Rings, as designed, had a high risk of failure given the severe cold that day.
One of the o-rings DID fail, but not until the shuttle was already in the air. At that point, it's WAY too late to scrub.
Clearly, you never read the EULA, or even the Warranty statement.
Microsoft only promises that it will work as intended for the first 90 days after it's installed. After 90 days, if Microsoft decides to tell you to piss off, you're SOL, because the software is presented to you AS-IS.
During the warranty period, if you have a problem, Microsoft will, AT THEIR SOLE DISCRETION, either refund the money you paid for the software (if you actually paid anything for it. If it came preinstalled on your computer, you paid nothing for the software - the computer maker did. You have to talk to them) or they can choose to fix the problem.
If you're outside of the warranty period and you don't have an active support contract, Microsoft doesn't have to care about your problems at all.
Ref:
Either that, or other countries will start exporting their nuclear waste to Japan. Probably some combination of both.
Did you know that Intel's chipsets include a very respectable ethernet controller? Have for a long time. Most motherboard manufacturers don't use them, though. For some reason, they'd rather bolt a suck-tastic Realtek controller onto one of the PCIe lanes, instead. Buying Intel-made boards is about the only way to get one that uses the on-chipset controller.... Unless you're going with an AMD CPU.
The way those tools work is that they write a customized firmware image onto the controller. (or an EEPROM, or the start of the flash) This way, if you don't need the thing to impersonate a CDROM, that code doesn't get loaded onto the chip. Specifics about partition sizes, read-only settings, etc, get tacked onto the end of the appropriate image as a data block.
If the chip manufacturer released a firmware update to address a bug in a previous release, the same tools can be used to install the firmware updates. You just have to replace the packaged images.
But you don't HAVE to use the bundled firmware images. A little legwork (or disassembly of the bundled firmwares) will yield all you need to know to write your own firmware for the thing that does whatever you want it to. Frequently, like the MV6208, the controller is built around an 8051-derivative. ( ref: http://www.belinking.com/downl... ) knowing that, you can write your own custom firmware that enumerates as a second keyboard to try and run commands. Or whatever else you want to make it do.
Hell, even the controllers in SD Cards can be exploited to run arbitrary code - http://bunniefoo.com/bunnie/sd...
How uninformed you are!
https://forums.hak5.org/index.php?/topic/8630-collection-of-production-tools-for-usb-devices/ is a discussion of "production tools" for USB flash drives.
These tools are specific to the controller in the flashdrive (chipsbank, micov, etc) and allow you to do things like change what size the drive reports itself as, load files onto the thing and make it behave as a read-only flash drive, load files on and make it behave as a USB CD/DVD-ROM drive with a disk preloaded, make it behave as a single flashdrive with multiple partitions, make it come up on the USB bus as a compound device consisting of any combination of the above.
My company uses these sorts of tools to distribute software on read-only flashdrives.
That's why it's important to actually read what they wrote instead of just stopping at the first "red flag" you come to.
They already have finalized hardware in production. They're not trying to fund hardware development and production. They've already done that. They're using indiegogo as an advertising channel and as a secondary storefront.
The steering wheel.
Most vehicles (if not all) being marketed for consumer road use have power steering. The standard (in the USA, if not globally) is to use hydraulics to help you move the wheels back and forth as you steer.
Those two models of Audi use electric motors to provide power assist, instead. That makes it MUCH easier to interface the control system.
Yes. If you're using libressl and the snapshot of the source you compiled is older than Thu Jun 5 15:46:24 2014 UTC, you're affected by this, too. See: http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/ssl/s3_clnt.c
Sure there is. the thing has a USB port that's used for charging.
duckintheface didn't say it wasn't being used in court.
the statement was that it can't [LEGALLY] be used in court.
Dude. Some shit ain't going to get upgraded no matter how many times you taze that dead horse.
Hell, I've still got SunOS 4.0 in production.
What's LinkedIn?
The entry for "Alpha Particles" was updated from "Harmless." to "Mostly Harmless." quite some time ago. Because it is... AS LONG AS the emitter is *OUTSIDE* the body.
An alpha particle is going to steal electrons from the first molecule it comes in contact with, and become a helium atom. If you're exposed to alpha radiation from the outside, it's going to hit and react with the layer of already dead skin cells called the epidermis.
So yes, as long as you don't swallow, inhale, inject, or otherwise insert the alpha-emitting radioisotope, you're probably going to be just fine.
You are correct. If it is distributed in the USA, and it crosses state lines, the FDA has jurisdiction on it. EVEN IF IT'S FREE.
The fact that Google Play is run by an American company is not the issue.
Whether or not your app is available to be downloaded in the US is. Because you're importing your app into the US to be used by Americans.
But that's a side issue. EVEN BY AUSTRALIA'S STANDARDS your app likely qualifies as a medical device. If you're not already registered with the Ministry of Health as a medical device manufacturer, I would highly recommend contacting someone to confirm with them whether your app should be regulated under Australian law, and whether you're breaking the law by distributing it (or allowing it to be distributed) in Australia without registration.
And then do the same thing with every other country your app is downloadable in. Because every country's regulations may be somewhat different.
DISCLAIMER: I am, (among other hats) a software developer for a medical device manufacturer in the United States.
Seriously, people. The FDA's stance has *ALWAYS* been that if something has a medical purpose or is an accessory to a medical device, then it *IS* a medical device, even with software. See: Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices, dated 2005.
So, yes, apps with a medical purpose are medical devices, just like any other piece of software.
Which means they *ARE* subject to the "Obamacare Tax" -- Which is *NOT* a "sales tax" to be paid by the consumer. It's an "income tax" to be paid by the manufacturer / developer.
This also means that if your app is categorized as a medical device, you (the developer) have to register with the FDA as a device manufacturer, which costs a couple thousand dollars a year, and means that every few years, the FDA sends someone out to review your quality control system, which includes your testing methodologies, what complaints you've received and how you've handled them, how you document your development process, etc.
AND what your software does determines what kind of medical device the FDA calls it. And the kind of medical device determines whether you are required to get the FDA's permission before you distribute it. (even if you distribute it for free) And yes, applying for that permission costs money, whether it's approved or not.
And, by the way: Each country makes its own rules about what makes a medical device and what you're required to do to be able to legally distribute it in that country. And in most countries that includes software.
I can see the argument that if you're limited in any way as to what you can do with your connection then it's not strictly neutral. I disagree with it completely, especially if the connection was sold under a "residential, not publicly accessible" contract. If this were about what content I could access via that connection, or how traffic from different providers / protocols is prioritized, THAT would be a neutrality issue.
If your connection is behind a NAT (carrier grade or otherwise) where you're sharing an IP with multiple other users, that's going to prevent you from being able to run a server that can accept connections from the outside world. -- unless your ISP adds rules to their router to ensure that certain ports on your connection are always available to the outside world. And if you want access to the standard ports (80, 53, 443, 25, 22, etc) they have to ensure that "your IP" is unique, at least among the subset of customers that want that ability.
Carrier grade NAT is only necessary because of widespread refusal (including among carriers) to adopt IPv6. But even without NAT, I still wouldn't have a problem with the ISP saying you can't run a server on a residential connection. Because IP space isn't the only limited resource in play.
The difference here is the guy who went to talk to the police on his own (ie voluntarily) vs being arrested (ie unwillingly).
Actually, the guy DIDN'T go to the police on his own. The police came to his house and started asking him questions, then they brought him to the station.
The differences between what happened and "an arrest" are that he was not mirandized and (presumably) was not handcuffed. It's still possible that the officers led him to believe he didn't have much choice in the matter.