I think OP is trying to do the second one [...convince someone else to do it...] with this article. Perhaps someone will read this and be embarrassed enough to fix it.
Or perhaps it will backfire to discourage other people from posting future embarrassing articles every time someone has a problem where they consider a change a bug, and want the behaviour reverted?
A "shame the developer" post to Slashdot is not the same thing as pinging the developer directly, and makes this really undesirable to fix, as it implies that similar pressure would work on the same developer in the future. If I'm a volunteer, I really don't appreciate you making demands on my time with the threat of publicly thrown tomatoes to back up your demands should I not meet them in a fashion you consider timely.
It's also pretty ass to insist on a release schedule for a change (see previous post: what the OP wants is technically not a "fix", since it perpetuates inappropriate software layering) to software which is not normally released on a schedule, and which does not have specific changes preannounced until the code is actually done, since they may or may not make a particular release.
If you want that, with respect, you should consider running only Canonical releases, and buying a support contract from Canonical, or if you don't like that, make friends with someone else who has already bought one.
Read the bug report. The accessibility feature works. The submitter (who also happens to be the bug reporter) found a fairly minor subfeature (the ability for sticky key modifiers to act as lock keys) has been broken recently. I say fairly minor, because the only key this might be critical for in certain use cases is the Shift key, where a separate Caps Lock is already available.
The bug is asking for the wrong fix
Different modifiers have different combinatorial effects. Caps Lock is not necessarily Caps Lock, in other words. I know that most Linux people hate them because they are cheap, and you have to do a "disable secure boot" dance to install Linux on them, but ChromeBooks, in particular, lack a Caps Lock key. Caps Lock is achieved by hitting both shift keys simultaneously.
If that isn't convincing enough, consider Alt-Gr vs. Right-Alt behaviour on international keyboards that report a USB HID country code of 00h.
While I was working on ChromeOS at Google, there were a number of obvious usability issues for the OS, but the majority of them stemmed from the need to upstream support into Linux, and the difficulty of doing this without involving an Alan Cox, Ingo Molnar, or similar personage when you were dealing with things which crossed area boundaries. Input is one of these areas, and it was rather difficult and roundabout to get support for non-adjusted raw system time stamps in evdev inputs, even as a non-default option.
Exaggerating the issue by claiming it makes accessibility on Xorg unusable and bitching on slashdot because its been a whole 11 weeks since he found the problem and noone has released a fixed version yet is just grandstanding.
I agree the issue is exaggerated, but mostly because I disagree about where in the input stack usability issues should be addressed. The usability belongs in the input stack, as does the internationalization, below the point at which events are reported to the console, or to X (or Wayland or whatever display server is handling the apps and forwarding the input events).
It's pretty easy to see where this breaks down by enabling "programmer mode" (meaning: disabling "secure boot mode") on a ChromeBook, and enabling root or other console logins. It's easy to see the shift-shift (or Caps Lock, if you plug in a standard USB keyboard) and internationalized input don't work the same on the console as they do in the graphical environment.
In general, the input stack in Linux has a *lot* of problems. A fun experiment to try is plugging in 3 or 4 USB keyboards, and playing with the Caps Lock; the light goes on or off on whatever keyboard you're playing with it on, but the actual Caps Lock state depends on whether you've hit the Caps Lock key on an even or odd number of keyboards, and the keyboard Caps Lock lights very quickly become desynchronized from the actual Caps Lock state (i.e. turning Caps Lock on on keyboard A lights the light on A, and hitting it on B turns it on on B, rather than off on A, even though the state is that Caps Lock is no longer in effect).
Similar issues occur when using sticky modifiers for usability, and when moving between virtual consoles with various modifier/Caps Lock/etc. states in effect.
I understand the idea that you may wish to explicitly allocate resources in a multihead environment, but the input stack really doesn't do that very well, either - these modifiers should happen in the input stream above a stream join as a resource allocate by a virtual console or display server, and not in the display server or the underlying driver.
Windows doesn't support multihead well (at all, for multiple sessions, without something like Citrix intermediating the process), but it also doesn't screw up on where it put the internationalization translation tables and the dispatch routines and the usability.
PS: In case you care, AFAIK, there are zero vendors who put the correct internationalization keyboard code type in the USB capability report for keyboard HID devices like they are supposed to; in general, it's handled by using an internationalized version of Windows instead - in other words, the correlation between the keyboard on your laptop and the OS is done via a ROM/EAROM device capabilities region, even if the internal keyboard in your laptop is interfaced via USB.
No. The map was made using existing data on known nuclear reactors and their power output and extrapolating what their antineutrino signature should look like. However, if geophysicists install detectors that show strong signatures that do not match up with the map given here, then that might be evidence for clandestine nuclear activity.
Yes. I see from the map that it's missing a number of known nuclear stations, for which the IAEA is unable to obtain data, and it's missing a number of "natural reactors" such as Oklu in Gabon, as well as a significant number of former Soviet reactors that are known to still be in use. It's also missing data for several Middle East reactors, known sites in South America, and a number of U.S. Military sites.
Assuming they get their experiment detectors running at all, they should be able to detect unreported nuclear reactor activity, but they'll have a hard time distinguishing it from the non-reactor related events they are seeking with the detectors.
http://www.gpstk.org/bin/view/...
http://www.rtklib.com/
http://gnss-sdr.org/
Next time do your own google search.
The batteries last too long!
Quick! Add more electroluminescent wire! Hurry Robin, the the Maker Faire!
You pay for access to the network of your provider and this has nothing to do with the provider - supplier communications.
Can I have another provider, then, please?
What do you mean "There's an infrastructure monopoly due to rights of way, and they won't let Google hang fiber optic cables on their telephone ples" ?
Don't these things sell a bit more slowly than MS predicts?
Not when Microsoft buys them from the vendors themselves, and then warehouses them. The problem is that old stock is removed from the front, and new stock is loaded in at the back, so unless they hit their predicted sales numbers, you get the older stock.
Microsoft just promised that they would ship (eventually); the only date involved is the date they made the promise, not a dealine by which the new stuff would be shipping exclusive of the old stuff, and certainly not the unsold stuff already in the channel.
What we have here is the use of an ambiguous generational designator that has nothing to do with the clock speed, and a journalist suffering sour grapes over not getting the faster model that has exactly the same description.
How about we blend it with DU and 'burn' it in a reactor?
Heretic!
How dare you propose a solution which is both workable by examples in France and Japan, and fails to support the idea that wind and solar can provide all the power we need (ignore the Solyndra behind the curtain)?!?!?!
I'm pretty sure we burned Joan of Arc at the stake for less than that!
I can see why parent is marked insightful... the more packets coming through a router, the more friction there is on the wires and other electronic components, the faster things wear out.
AT&T probably has an entire team of people who go around measuring wear and tear on routers and wiring using calipers.
The guy did not actually recommend what you just said. He suggested a software fix where if brake and gas are both pressed, the brake would over-ride the gas pedal. So brake would always stop the car independent of whether the gas pedal was pressed.
According to the comments section, it already works that way. Also, if you look at the pictures of the pedals, the brake pedal area is huge compared to the gas pedal area. While I personally like a long gas pedal hinged at the bottom, compared to a small square one, it's pretty clear his heel was too far right for braking. He probably needs to adjust his seat forward to increase his foot rotation.
Great assumed premise, guys, really.
We've jumped way past the point of claiming that polarized background cosmic radiation = gravitational waves detected (right now, the polarization is just consistent with a theory that, IF there are gravitational waves, AND a particular inflation theory requiring gravitational waves to be possible is correct, THEN the observed polarization is consistent with fossil pre-inflation gravitational waves.
We are now to the point of "alternate explanations for the gravitational waves 'observed' by BICEP2".
It's like seeing a headline that says "Aliens meet with Jimmy Carter!" in a supermarket tabloid, and then arguing about whether or not they met with Jimmy Carter, instead of arguing about whether or not aliens landed on Earth... or arguing about whether or not they landed on Earth, rather than whether aliens exist in the first place.
As long as it passes VSC5, I don't care.
They could put antlers on the thing, as long as it continues to pass the POSIX conformance test suite Validation Suite for Commands version 5, it doesn't matter, my medulla will be able to still type the commands to operate it while I'm up in my cerebral cortex thinking about higher level problems than "will typing this command too many times give me carpal tunnel syndrome like RMS has from emacs use?" or "how an I get a graduate student to take dictation into an editor for me, rather than aggravating my carpal tunnel syndrome acquired from emacs use?".
No. Refusing to do a task is insubordination and grounds for termination.
See http://www.edd.ca.gov/UIBDG/Ab...
If you have an ethical or philosophical objection to training a replacement on the basis of the company terminating you afterward in order to save money, and they have no other reason (which they could not, given they feel you are qualified to train), then you can refuse, and if terminated for refusal, claim benefits.
You wanna know what's BS?
Treating companies as a place to get vocational training because your college degree is nothing more than a union card because you didn't put in the effort required to actually *learn* something when you were at college, and you were more concerned with how much you thought you were going to be making when you picked your major than with actually liking or being good at the job?
That's pretty BS.
"There is such a fine line between genius and stupidity." - David St. Hubbins, "Spinal Tap"
