I agree that it's not important to have closely regulated voltage at the input. And most devices already don't care much.
But negotiation is important because lets power-consuming devices make decisions about what they do with the available power, should less than 240W be available, and allows power supplies to be built to this standard even if they cannot output a full 240W.
For example, if my laptop drew 240W while running and charging the battery, I'd need ~20A from my car to power it. But my car might only have a 15A outlet. Without negotiation the laptop cannot be plugged into the car at all, as it will blow the fuse. With negotiation the laptop can plug in and make a decision about whether or not there's enough power to do anything useful. It might, for instance, power the CPU but not charge the battery, or put the battery in a trickle-charge that takes longer but draws less power.
It's easy enough to run each program in its own sandbox. It's just that those programs then aren't very useful. I'd frequently like to download files and later open them in something other than my browser. And I'd rather like to be able to print directly from my web browser, rather than downloading files, using whatever external mechanism is allowed to transfer files among the sandboxes, and then opening lpr so I can send those files to my printer.
And as soon as you start poking holes in that system to let programs share disk space or talk to each other via IPC or sockets or whatnot you're in the same mess we have now -- all you really have is disk privileges and memory isolation to keep you safe. Systems like Apple's iOS provide pretty good sandboxing, but they do so at the cost of a lot of functionality that I'm not willing to give up. And even that leaves plenty of potentially exploitable holes.
Now, there are approaches (and this new system actually works along those lines, as does SELinux) that allow you to say things like "user A can write to ~/Downloads and ~/bin from their shell, but user A running program X can only write to ~/Downloads". That's not complete sandboxing, but does provide fine-grained controls to mitigate potential damage. Unfortunately it requires a very detailed profile of what is "normal" behavior for a specific user/program combination, and while that may be worthwhile on an Internet-facing server with no local users it would sure make it hard to do normal work on your self-administered desktop unless you were willing to continuously manage the behavior profiles.
He wants to have group-determined-by-name behavior and not from POSIX groups. I'll agree it's "easier" in that you don't have to make/use groups, but it's a terrible conflation of functionality which makes it easy to muck up in a whole variety of ways. Just wait until "Jeremy Testarossa" creates what he thinks is a perfectly reasonable username.
That being said, it would be trivial to setup a script that reads the list of users and builds the membership of related groups (possibly even creating groups) based on the username-embedded group names.
Is there something on your system that prevents you from escalating your privileges without sudo? I mean sure, minimal install set is a fine thing, but we're talking about 150k of data in/usr/sbin -- is it really a big problem for you? It seems a little like complaining that you always launch bash as bash proper and never as sh so the filesystem link annoys you and you're looking for a distro that doesn't include/bin/sh.
Also, being able to not set -- or have to remember or change -- a root password can be useful even on single-user systems. As can the ability to run specific programs with root privileges without authentication/etc., perhaps even limiting the arguments given to those programs to help keep their usage safe.
It's not gonna be used on public-facing systems either. Tools like SELinux are much more appropriate for a "lock down" state with known behavior. This system was designed to grant extra privileges for unpredictable operations, which while similar in construction to SELinux is exactly the opposite application. Just about the only application for such a tool is multi-user systems where high-level privileges are needed by people other than those administrating the machine, which has to be a vanishingly small fraction of UNIX-like systems. And even on such systems the admin will still use sudo to to their own work.
Most admins ignore sudo's existing granularity, so why would they want an even more granular system? I'm not saying this new system has no uses -- clearly it does or no one would have built it -- but it's ridiculous to claim that it's likely to replace sudo in common usage when 75+% of admins have never changed the the default sudoers file, let alone wanted more even more granular control.
And unison extends the rsync model to do bi-directional syncing with basically no user intervention and no strict need for a centralized server. It's not quite mobile-ready, but there's real work being one on an ocmal runtime for android, which is probably 99% of what you need to get unison working there as well.
I've yet to figure out what advantage it provides over grub-legacy, other than it compiles for x86_64. Sure, it's got more functionality but it's also harder to build, harder to install/configure, and in the typical use case it does literally nothing different. You could make the same argument for lilo over grub, and people did for a long time -- unless you actually want one of the new features it's a much more complicated system that gets you nothing useful. I personally liked the ability to switch kernels/etc. at boot time and made an early switch the grub, but I can absolutely see why the average user though lilo was good enough, and was willing to deal with floppy-rescue on the rare occasion that they forgot to update their kernel pointer.
Frankly the real problem is people still put up with crappy BIOS-based pre-boot environments. Most of the stuff grub2 tries to do should happen in the firmware, and on systems with OpenFirmware/decent UEFI implementations/etc. it does. Give the firmware support for a couple of common file systems and/or enough internal storage to stash the kernel internally, and just forget the whole on-disk bootloader. Add a standard programming language to that (as both UEFI and OpenFirmware did) and you can write arbitrary extensions for pre-boot functionality, to add functionality to older hardware without updating the underlying firmware.
Larger elements almost certainly existed in the past, but there's nothing bigger than Bi that's stable on astronomical time scales (and even Bi has recently been discovered to be slightly radioactive, albeit with a very long half-life), so any heavy elements that were created in normal astronomical events have long-since decayed into lighter elements -- when you get to 200+ nucleons "stable" is a relative term.
Why do you need clothes for a 2 week holiday? Surely you can reduce your time in public to keep your exposure down and spend 2 weeks enjoying your vacation rather than having your arms stuck in your clothes.
Or any other ridiculous variation. We all have different preferences and desires -- why are you trying to force yours on others?
No, it really can't. Essentially this same paper, but as an analysis of SIP-IPSec/SIP-TLS, was published not long ago. Any real-time, size-efficient voice codec leaks a ton of information about the underlying speech just in the rate and size of its packets, so any encryption system that is real-time and length-preserving (i.e. any system that would be considered suitable to be paired with the underlying codec) leaks the same information. You can add padding to hide this, but A) that defeats the purpose of your size-efficient codec and B) while I haven't read any papers specifically analyzing padding techniques in voice comm, the papers analyzing padding in general packet comm suggest it's hard to come up with a padding system that provides an effective screen without adding a significant amount of latency or wasting more bandwidth than you're actually using.
The easiest workaround is really to just use uLaw encoding (or any other CBR codec) so that the packet size and rate doesn't reveal anything about the content of the audio stream. As hacktour suggests, even using a VBR but general-purpose audio codec instead of a voice-specific one would help, though if you're worried about security I wouldn't take the risk (unless you really can't run CBR due to low available throughput).
Telcos could either charge people to install infrastructure (like a construction company) or build the infrastructure themselves and rent it out (like a landlord). They could maybe even get people to install their own infrastructure and the lease people the land it uses or charge for maintenance services (like a build-to-suit lease). But telcos don't do that -- they charge users for the infrastructure (either directly or via taxes) and then charge again for use of the infrastructure, and customers rightly avoid that scenario whenever possible.
Also telcos regularly fight against anyone trying to install communications lines in their domain, and governments continue to grant them exclusive rights to lay wires, so it's not like you can just go out on your own -- you have to buy into their game even if you're willing to provide 100% of your own infrastructure.
Why are we teaching children to do jobs that can be done by computers? Computers are terrible and math and really good at calculation -- why don't we divide the effort (and hence the instruction) along those lines.
I'm not saying we shouldn't teach children to do arithmetic, but there's a limited amount of math instruction time available, and I don't think we should waste it being sure Johnny can manually calculate large bits of long division instead of teaching him what division might actually accomplish.
If you want to be sure Johnny understands the calculation, have him write a program for his calculator that does it. Once he can do that he clearly understands the manipulation required so there's no reason to make him keep doing manually it when there's a $0.03 device that can do the same thing faster and more accurately.
To me this all seems equivalent to teaching kids to farm using ox-powered plows rather than tractors -- yes, it's important to understand how it works, but it's not important to be able to actually do it efficiently once you've got that understanding.
You would assume wrong. Warrants are required to enter commercial property, including workplaces. This applies to OSHA, fire inspections, etc., and has been tested in federal court (Marshall v. Barlow’s, Inc). There are cases where a business must subject itself to an inspection in order to qualify for a license or other certification. But that's the business owner requesting an inspection, not the government demanding one, and a failure to allow the inspection results in a failure to issue the license, not in a mandatory inspection or seizure of property. It works just like electrical inspections in your home -- when you have new work done, you must request an inspection, and a failure to pass an inspection might lead to your property being condemned, but at no point in the process are you required to submit to a search/inspection, and you if you choose to allow one you can prepare for it and limit the scope of the inspection to the relevant portions of your home.
If law enforcement has probable cause to believe that a business is participating in copyright infringement that can *already* get a warrant. No new law is needed to authorize that action. This law would mean that they don't need probable cause and can just come in and hassle legitimate business owners while threatening to seize the equipment necessary for their day-to-day operations, which doesn't sound much like justice to me.
Exactly. Like all security systems, it's not perfect. Using several together can mitigate the flaws in any one system. Biometrics are useful in that they don't require you to carry around anything -- hence they are user-friendly -- and are somewhat more difficult to fake than a traditional key (not necessarily harder to obtain, but at attended posts the guard could notice your fake thumb/eye/weight belt, whereas he could not be expected to notice a fake key). But any biometric scan you'd be willing to submit to on a regular basis is going to be so non-invasive that it probably could be carried out surreptitiously, so the data shouldn't be treated as a well-guarded secret.
Yes. But people keep envisioning (and sometimes implementing) authentication systems that use biometrics only, which is just as bad a plan as giving 500 people the same key to a building. So long as biometrics are paired with a second authentication factor that can be changed they still represent a net improvement in security, even if a copy of your biometric data becomes available and can be successfully substituted at the point of authentication.
Yeah, the older devices require 12V (FireWire) charging. New ones require 5V (USB) charging. There was also a change from FW-only to FW-or-USB to USB-only for data, but that had better overlap -- the power requirements just switched overnight.
You essentially can't live in a place without wireline telephone service, thanks to the universal service mandate. We decided as early as 1934 that it was vital to provide all people with communications services at a reasonable price. Why that mandate hasn't been extended to modern Internet service yet is beyond me.
Apple makes a lot more money from selling you downloadable movies than from adding a BR drive. And Apple tries pretty hard to keep everyone in the world in exactly the same configuration -- they don't want some machines that can do BR and some that can't, or to lock down their player software to ensure that only those with hardware configuration X are allowed to run it. Plus if they and MS can hold out long enough there's a good chance the licensing fees/technical requirements/etc. for BR players will go down so it's cheaper to add.
Not that I wouldn't love to see an actual BR player that supports the directory structure/PiP/etc., but you can use MakeMKV to rip or live-stream Blu-Rays on Win/Linux/Mac. It's not quite a click-and-go solution for your grandmother, but it's not linear algebra either.
There really is no need for a "legal test case" because there is no legal problem -- all sorts of businesses already offer free WiFi, and no one holds them liable for use by their customers or passersby.
The problem is the police are deciding that raids are a reasonable way to serve search and/or arrest warrants. And since the police don't raid Starbucks there's no reason to think they would raid EFF hotspots either. Instead they'll serve the search warrant in a reasonable way, in an attempt to collect the evidence they need to prosecute a crime. Just like they should do for individuals.
By this logic, we should remove public mail drops. Public mail drops are socially irresponsible because they leave an effectively traceless porthole into the entire physical world for any asshole to mail whatever he pleases. All mail senders should have to present ID and have their parcels carefully inspected to ensure they do not contain child pornography.
Can't I complain that the raid is happening in the first place? Unless there's an eminent threat to public safety the police should NEVER undertake a raid. I'd go so far as to argue that, given a situation that does require a raid, the police should only try to separate the public from danger and should call the military to deal with the threat -- that's what the military is for.
But most of the raid we undertake are intended to preserve evidence, or to capture a not-terribly-ellusive suspect, and that is utterly absurd. We risk the lives of police as well as the privacy, piece of mind, and lives of the public, for the sake of preventing someone from flushing their drugs or running out the back door.
Slashdot Mirror
I agree that it's not important to have closely regulated voltage at the input. And most devices already don't care much.
But negotiation is important because lets power-consuming devices make decisions about what they do with the available power, should less than 240W be available, and allows power supplies to be built to this standard even if they cannot output a full 240W.
For example, if my laptop drew 240W while running and charging the battery, I'd need ~20A from my car to power it. But my car might only have a 15A outlet. Without negotiation the laptop cannot be plugged into the car at all, as it will blow the fuse. With negotiation the laptop can plug in and make a decision about whether or not there's enough power to do anything useful. It might, for instance, power the CPU but not charge the battery, or put the battery in a trickle-charge that takes longer but draws less power.
There's no technology available to record the actual scents -- it would all have to be programmed, like sound effects.
It's easy enough to run each program in its own sandbox. It's just that those programs then aren't very useful. I'd frequently like to download files and later open them in something other than my browser. And I'd rather like to be able to print directly from my web browser, rather than downloading files, using whatever external mechanism is allowed to transfer files among the sandboxes, and then opening lpr so I can send those files to my printer.
And as soon as you start poking holes in that system to let programs share disk space or talk to each other via IPC or sockets or whatnot you're in the same mess we have now -- all you really have is disk privileges and memory isolation to keep you safe. Systems like Apple's iOS provide pretty good sandboxing, but they do so at the cost of a lot of functionality that I'm not willing to give up. And even that leaves plenty of potentially exploitable holes.
Now, there are approaches (and this new system actually works along those lines, as does SELinux) that allow you to say things like "user A can write to ~/Downloads and ~/bin from their shell, but user A running program X can only write to ~/Downloads". That's not complete sandboxing, but does provide fine-grained controls to mitigate potential damage. Unfortunately it requires a very detailed profile of what is "normal" behavior for a specific user/program combination, and while that may be worthwhile on an Internet-facing server with no local users it would sure make it hard to do normal work on your self-administered desktop unless you were willing to continuously manage the behavior profiles.
He wants to have group-determined-by-name behavior and not from POSIX groups. I'll agree it's "easier" in that you don't have to make/use groups, but it's a terrible conflation of functionality which makes it easy to muck up in a whole variety of ways. Just wait until "Jeremy Testarossa" creates what he thinks is a perfectly reasonable username.
That being said, it would be trivial to setup a script that reads the list of users and builds the membership of related groups (possibly even creating groups) based on the username-embedded group names.
Is there something on your system that prevents you from escalating your privileges without sudo? I mean sure, minimal install set is a fine thing, but we're talking about 150k of data in /usr/sbin -- is it really a big problem for you? It seems a little like complaining that you always launch bash as bash proper and never as sh so the filesystem link annoys you and you're looking for a distro that doesn't include /bin/sh.
Also, being able to not set -- or have to remember or change -- a root password can be useful even on single-user systems. As can the ability to run specific programs with root privileges without authentication/etc., perhaps even limiting the arguments given to those programs to help keep their usage safe.
It's not gonna be used on public-facing systems either. Tools like SELinux are much more appropriate for a "lock down" state with known behavior. This system was designed to grant extra privileges for unpredictable operations, which while similar in construction to SELinux is exactly the opposite application. Just about the only application for such a tool is multi-user systems where high-level privileges are needed by people other than those administrating the machine, which has to be a vanishingly small fraction of UNIX-like systems. And even on such systems the admin will still use sudo to to their own work.
Most admins ignore sudo's existing granularity, so why would they want an even more granular system? I'm not saying this new system has no uses -- clearly it does or no one would have built it -- but it's ridiculous to claim that it's likely to replace sudo in common usage when 75+% of admins have never changed the the default sudoers file, let alone wanted more even more granular control.
And unison extends the rsync model to do bi-directional syncing with basically no user intervention and no strict need for a centralized server. It's not quite mobile-ready, but there's real work being one on an ocmal runtime for android, which is probably 99% of what you need to get unison working there as well.
I've yet to figure out what advantage it provides over grub-legacy, other than it compiles for x86_64. Sure, it's got more functionality but it's also harder to build, harder to install/configure, and in the typical use case it does literally nothing different. You could make the same argument for lilo over grub, and people did for a long time -- unless you actually want one of the new features it's a much more complicated system that gets you nothing useful. I personally liked the ability to switch kernels/etc. at boot time and made an early switch the grub, but I can absolutely see why the average user though lilo was good enough, and was willing to deal with floppy-rescue on the rare occasion that they forgot to update their kernel pointer.
Frankly the real problem is people still put up with crappy BIOS-based pre-boot environments. Most of the stuff grub2 tries to do should happen in the firmware, and on systems with OpenFirmware/decent UEFI implementations/etc. it does. Give the firmware support for a couple of common file systems and/or enough internal storage to stash the kernel internally, and just forget the whole on-disk bootloader. Add a standard programming language to that (as both UEFI and OpenFirmware did) and you can write arbitrary extensions for pre-boot functionality, to add functionality to older hardware without updating the underlying firmware.
Larger elements almost certainly existed in the past, but there's nothing bigger than Bi that's stable on astronomical time scales (and even Bi has recently been discovered to be slightly radioactive, albeit with a very long half-life), so any heavy elements that were created in normal astronomical events have long-since decayed into lighter elements -- when you get to 200+ nucleons "stable" is a relative term.
Why do you need clothes for a 2 week holiday? Surely you can reduce your time in public to keep your exposure down and spend 2 weeks enjoying your vacation rather than having your arms stuck in your clothes.
Or any other ridiculous variation. We all have different preferences and desires -- why are you trying to force yours on others?
No, it really can't. Essentially this same paper, but as an analysis of SIP-IPSec/SIP-TLS, was published not long ago. Any real-time, size-efficient voice codec leaks a ton of information about the underlying speech just in the rate and size of its packets, so any encryption system that is real-time and length-preserving (i.e. any system that would be considered suitable to be paired with the underlying codec) leaks the same information. You can add padding to hide this, but A) that defeats the purpose of your size-efficient codec and B) while I haven't read any papers specifically analyzing padding techniques in voice comm, the papers analyzing padding in general packet comm suggest it's hard to come up with a padding system that provides an effective screen without adding a significant amount of latency or wasting more bandwidth than you're actually using.
The easiest workaround is really to just use uLaw encoding (or any other CBR codec) so that the packet size and rate doesn't reveal anything about the content of the audio stream. As hacktour suggests, even using a VBR but general-purpose audio codec instead of a voice-specific one would help, though if you're worried about security I wouldn't take the risk (unless you really can't run CBR due to low available throughput).
Telcos could either charge people to install infrastructure (like a construction company) or build the infrastructure themselves and rent it out (like a landlord). They could maybe even get people to install their own infrastructure and the lease people the land it uses or charge for maintenance services (like a build-to-suit lease). But telcos don't do that -- they charge users for the infrastructure (either directly or via taxes) and then charge again for use of the infrastructure, and customers rightly avoid that scenario whenever possible.
Also telcos regularly fight against anyone trying to install communications lines in their domain, and governments continue to grant them exclusive rights to lay wires, so it's not like you can just go out on your own -- you have to buy into their game even if you're willing to provide 100% of your own infrastructure.
Why are we teaching children to do jobs that can be done by computers? Computers are terrible and math and really good at calculation -- why don't we divide the effort (and hence the instruction) along those lines.
I'm not saying we shouldn't teach children to do arithmetic, but there's a limited amount of math instruction time available, and I don't think we should waste it being sure Johnny can manually calculate large bits of long division instead of teaching him what division might actually accomplish.
If you want to be sure Johnny understands the calculation, have him write a program for his calculator that does it. Once he can do that he clearly understands the manipulation required so there's no reason to make him keep doing manually it when there's a $0.03 device that can do the same thing faster and more accurately.
To me this all seems equivalent to teaching kids to farm using ox-powered plows rather than tractors -- yes, it's important to understand how it works, but it's not important to be able to actually do it efficiently once you've got that understanding.
You would assume wrong. Warrants are required to enter commercial property, including workplaces. This applies to OSHA, fire inspections, etc., and has been tested in federal court (Marshall v. Barlow’s, Inc). There are cases where a business must subject itself to an inspection in order to qualify for a license or other certification. But that's the business owner requesting an inspection, not the government demanding one, and a failure to allow the inspection results in a failure to issue the license, not in a mandatory inspection or seizure of property. It works just like electrical inspections in your home -- when you have new work done, you must request an inspection, and a failure to pass an inspection might lead to your property being condemned, but at no point in the process are you required to submit to a search/inspection, and you if you choose to allow one you can prepare for it and limit the scope of the inspection to the relevant portions of your home.
If law enforcement has probable cause to believe that a business is participating in copyright infringement that can *already* get a warrant. No new law is needed to authorize that action. This law would mean that they don't need probable cause and can just come in and hassle legitimate business owners while threatening to seize the equipment necessary for their day-to-day operations, which doesn't sound much like justice to me.
What happens in PowerShell when that object you're piping out of program 1 isn't one of the supported object types in program 2?
Exactly. Like all security systems, it's not perfect. Using several together can mitigate the flaws in any one system. Biometrics are useful in that they don't require you to carry around anything -- hence they are user-friendly -- and are somewhat more difficult to fake than a traditional key (not necessarily harder to obtain, but at attended posts the guard could notice your fake thumb/eye/weight belt, whereas he could not be expected to notice a fake key). But any biometric scan you'd be willing to submit to on a regular basis is going to be so non-invasive that it probably could be carried out surreptitiously, so the data shouldn't be treated as a well-guarded secret.
Yes. But people keep envisioning (and sometimes implementing) authentication systems that use biometrics only, which is just as bad a plan as giving 500 people the same key to a building. So long as biometrics are paired with a second authentication factor that can be changed they still represent a net improvement in security, even if a copy of your biometric data becomes available and can be successfully substituted at the point of authentication.
Yeah, the older devices require 12V (FireWire) charging. New ones require 5V (USB) charging. There was also a change from FW-only to FW-or-USB to USB-only for data, but that had better overlap -- the power requirements just switched overnight.
You essentially can't live in a place without wireline telephone service, thanks to the universal service mandate. We decided as early as 1934 that it was vital to provide all people with communications services at a reasonable price. Why that mandate hasn't been extended to modern Internet service yet is beyond me.
Apple makes a lot more money from selling you downloadable movies than from adding a BR drive. And Apple tries pretty hard to keep everyone in the world in exactly the same configuration -- they don't want some machines that can do BR and some that can't, or to lock down their player software to ensure that only those with hardware configuration X are allowed to run it. Plus if they and MS can hold out long enough there's a good chance the licensing fees/technical requirements/etc. for BR players will go down so it's cheaper to add.
Not that I wouldn't love to see an actual BR player that supports the directory structure/PiP/etc., but you can use MakeMKV to rip or live-stream Blu-Rays on Win/Linux/Mac. It's not quite a click-and-go solution for your grandmother, but it's not linear algebra either.
There really is no need for a "legal test case" because there is no legal problem -- all sorts of businesses already offer free WiFi, and no one holds them liable for use by their customers or passersby.
The problem is the police are deciding that raids are a reasonable way to serve search and/or arrest warrants. And since the police don't raid Starbucks there's no reason to think they would raid EFF hotspots either. Instead they'll serve the search warrant in a reasonable way, in an attempt to collect the evidence they need to prosecute a crime. Just like they should do for individuals.
By this logic, we should remove public mail drops. Public mail drops are socially irresponsible because they leave an effectively traceless porthole into the entire physical world for any asshole to mail whatever he pleases. All mail senders should have to present ID and have their parcels carefully inspected to ensure they do not contain child pornography.
Can't I complain that the raid is happening in the first place? Unless there's an eminent threat to public safety the police should NEVER undertake a raid. I'd go so far as to argue that, given a situation that does require a raid, the police should only try to separate the public from danger and should call the military to deal with the threat -- that's what the military is for.
But most of the raid we undertake are intended to preserve evidence, or to capture a not-terribly-ellusive suspect, and that is utterly absurd. We risk the lives of police as well as the privacy, piece of mind, and lives of the public, for the sake of preventing someone from flushing their drugs or running out the back door.