What exactly would you propose to add? This isn't a matter of implementing new functionality, but rather removing fundamental misfeatures. Any change to address this issue is going to end up breaking existing applications which depend on the original input behavior.

Oh how about a new protocol extension that allows one designated program to receive all keyboard inputs regardless of any other grabs. The X11 server can keep on pretending that the other grabbers still have such a grab.

Look: X11 works on Windows even though windows can apparently REALLY gab the keyboard. X11 will we are told work on Wayland too despite the fact that wayland can apparently REALLY grab they keyboard. Do you really think it couldn't be extended to do that itself?

Which could be a good argument for replacing X. It is rather old technology, perhaps it is time to update it to something newer, rather than clinging to it and claiming it is all one needs.

Or how about adding a protocol extension to deal with this security problem as has been done a number of times in the past for authentication. I don't understand why X11 seems to get special treatment here.

Program has security flaw. Response "has it been patched yet"

X11 has security flaw: we can't possibly patch it we must discard everything and start again.

There's certainly some things wrong with X11, but this is one which could be solved easily. It could, for example, be done by having a "kill all grabs" command which is available to the window manager.

Uh.

Why can't I have my screen locker have a passive grab on Ctrl+Alt+Delete or shift+altgr+control+` or whatever, using XGrabKey. That way if someone else installs a screenlock faker then I'll know because it won't respond to the magic key presses.

The thing is on Windows it never worked as well as it ought to. The reason is that if the screen said something like:

"pls entar u r passwordz to login"
[ password box ]
[OK]

"pls wate wile redirecting to http://scamsite.ru/yourbank"

"Pls entar u r bank passwrd thx"

an appalingly large number of people would have dilligently followed those steps. the ctrl+alt+delete thing was fine but required more knowledge than 99.9% of users had.

Oh and the active grab thing: if you ever hear a wayland dev tout that as a problem, please kick them in the nuts because it XFree86 USED to have a feature for killing grabs from a keystroke, until the fuckers who went on to develop Wayland decided we didn't really need it because "it would only be needed if a program is buggy". Well, no fucking shit hotshot.

Why is this considered acceptable? Get physical access to my iPhone (for example - Android is probably the same?), good luck getting in.

Huh? This exploit only works if someone has already had access to your unlocked computer long enough to load and run malicious code. It's not like oyu can plonk down someone at a computer wit ha locked screen and have them hack in by being clever.

And if I had access to your unlocked iPhone, could I not root it or whatever the iPhone cracking is called and install a fake screenlocker too? Or hell, install a custom keyboard app which looks like the normal one but saves all passwords and sends them to the cloud. I might not even need to root it to do that.

Well, yes.

However, that only works if the attacker already has arbitrary local code execution. If they can do that then they can trojan every single program, by diddling with the PATH environment variable and/or pissing with LD_PRELOAD.

Basically yes, it's a hole but one that only kicks in if you're fucked 6 ways to Sunday already.

Or if you've done xhost+ and disabled your firewall. But that hasn't been the default in years.

What happened?

I'm guessing that people got fed up with churn and started to realise that change for its own sake is annoying. Getting irritated at having to get used to a new system AGAIN that does things worse in many cases is not unreasonable. Being fed up with churn is not the same as fearing change.

Personally, I like to see "change" actually make things better, because if it doesn't then why bother with the change? And if it makes things worse, then WTF?

A lot is just uninspiring and meh. Going from flat to bevelled to bulbousd and back to flat (hello Athena!) user interface elements is just a huge meh. I mean sure, now they're coloured and antialiased and with nice fonts and whetever, but I really can't feel myself getting excited about "flat" design. Actually, personally I think it's a bit of a usability regression becase it's harder to explain to people which the active user interface elements are.

Change where it's an improvement I like. I like large, high res screens. I like running a modern kernel with all the new power saving features and better, newer filesystems and so on and so forth. I tend to run recentl builds of tools I like like vim and mplayer because the changes make them better than the old version. I keep promising myself I'll finally switch from Xterm to Terminology, but I can't get some of the features to work properly at the moment.

All those things, all those changes have made stuff better. On the other hand, I still run FVWM2. I've tried more modern things, but they all seem to make things worse in interesting ways. I've still adopted some changes, however which make it more modern.

I think there are quite a few people here with similar opinions to me. Another example: the reason that tablet stuff coming to laptops is bad is because a lot of the UI stuff is designed around single, non cooperating, full screen apps. I don't want that, not because I fear change, it's because I changed AWAY from it in the 90s and I have no desire to go back to the bad old days. I remember what it was like all too well (and my phone just keeps on reminding me). What I fear is being dragged back to something I know from experience is inferior.

Nope: there still needs to be a sliding contact between the wheel and a fixed cable somewhere.

Anyway, sliding contacts work just fine. See, e.g. trains with 3rd rail, 4th rail, pantograph and mixed mode trains and trolley busses and even some whacky covered contact trams.

The latter are particularly interesting. Some cities want an electric tram installed but don't want to have overhead cables or exposed foot level contacts. So, there are studs in the ground and they only switch on after the tram has made contact. The old systems were unreliable, but with modern arc-free power semiconductors, they work well and no arcing.

Indeed, and I think it's reasonable to call out the posters who say "oh they're idiots, why don't they just..." and so on and so forth.

However, it IS fun to speculate with a bunch of reasonably knowledgable people on mechanisms for going beyond what is currently technically feasible.

The powered lift with a rack and pinion is an interesting idea. I'm struggling to work out how much additional power it would take. With a short lift, you can discount the weight of the cable, and so you can have the lift counterbalanced easily and the motor must lift the ddifference between the two sides plus the friction.

With a long cable, the weight to be lifted changes with height: the further down the lift goes, the higher the weight. If you counterbalance with the same mechanism, then the balance will only be equal in the middle. At the bottom, you need to lift the entire weight of the cable, which in a high lift can be more than the lift.

At that point, having a motor which can lift the entire lift minus the cable isn't infeasible. Of course, you have to lift the motor too. And then there's the problem of power delivery. Maybe something like a train pickup could be adapted to work.

The power will be enormous, but one could offset it at a building scale using energy recovery, either have lifts run in oppsition where the descending one powers the rising one, or have the lifts all connected into a busbar which has some large piece of rotating flywheel storage to absorb or emit energy as required.

Apparently there are a few companies working on cableless elevators for exactly these reasons. Some have linear motors instead of a rack and pinion.

My son was reading for content (Pokemon game guides) before he was reading for pleasure

Er, how is that not for pleasure?

Besides, my point still stands. No one says you must learn to read so you can understand voter registration forms or whatever.

Apparently "many eyes" were not reading that bit of code.

Will you please actually read the quote rather than quoting an inorrect interpretation. The quote is:

"given enough eyeballs, all bugs are shallow"

It means that once a bug is found, it is shallow, i.e. quick and easy to solve for someone. It doesn't and never did mean that all bugs will be found.

Oh gee, and here I thought it meant merge basic blocks.

Nope. As you pointed out yourself it's only a hint to the compiler whether to actually inline or not. When it is not inlined, the symbol has to be weak, because the function may be exported in may object files: which ever object files have a corresponding source file which includes the function.

Therefore all inline really means is "export as a weak symbol".

Do you know _anything_ how C++ compilers even work??

Yes, which is why I know that thing about weak symbols. You apparently do not.

You love to constantly make incorrect and incomplete assumptions.

Well no.

2. Gee, why do things like _Profiling_ exist. The *compiler* doesn't have access to *run-time* performance. The optimizer is dealing with a _subset_ of data. It doesn't know the "function temperature"

Compiling (under gcc) with -fprofile-arcs, running the program generates that information. Recompiling with -fpbranch-probabilities then tells the optimizer to use the run-time information. That said, I don't think function temperature has much to to with whether to inline or not.

1. I want to write ONE directive not clutter my code up with hacks PER compiler. _Why_ do standards exist ? To make everyone's live _easier_.

And anyway, you still ignored my point. The committee have standardised function attributes, which is 95% of the way towards having what you want. Write a proposal to add force_inline as a standard attribute.

So Verizon accepted a fine of $5,000,000. For Verizon, I call that a success. Given their size nothing at all is going to cost them less than 5 million. There is no way in hell that investigations into rural phone problems would have cost less.

This is just the cost of doing business, and it's certainly more profitable to break the law and pay the fine than it is to do what they are supposed to do.

Until the fines are set to a level to remove all profit and THEN put a punishment on top, large business will continue to flout the law because it's more profitable.

Do you _actually_ use different compiles on different platforms at all ????

Yep.

'inline' is only a hint

Inline specifically means "export this as a weak symbol".

I can chose between Microsoft's __inline or GCC god-awful __attribute__((always_inline)) syntax.

Yes, but why are you trying to do that? You're fighting the optimizer and you're almost certain to lose.

Nonetheless you're ignoring the other part of the reply that the C++ committe has in fact standardised a way of specifying attributes. Why don't you submit a paper specifying some always inline attribute?

You're constantly complaining about "breaking things." Gee, if only there was a way to migrate, mitigate, and deploy change ...

You wishing something to be the case dosen't make it happen. Unlike your silly car analogy, there is no government body who will arrest and detain anyone using C++98 after some flag day. As a result it will cause fragmentation just like Python 3.

Gee, why does Microsoft provide a _specific_ number for _each_ warning ???

Uh? Again, there is no language where error messages are standardised. The fact that MS provides numbers for each one is a total red herring. Like I said, complaining that the C++ committee have their heads up their arses because they're not standardising something that no other language spec ever standardised is basically idiotic.

But now you've wandered into bizarro world with warnings. So what would the procedure be? The warnings which a compiler is capable of emitting depend quite strongly on the code analaysis part which is in part dependent on the optimizer. There is no way to get GCC, LLVM, VS and ICC to have exactly the same set of warnings. And then what would the procedure be for new warning?

Seriously, the standards committee cannot make something happen by magic. If they try to do something that no one is going to implement then it's a pointless and destructive waste of time. They learned their lesson very well with exported templates. All sorts of people begged and whined for it, so they did it. They didn't listen to the howls of anguish from the compiler writers. All that happened was a dead stub of a standard which almost no compilers ever supported.

This is a solution in search of a problem.

So you're saying that the C++ commitee shouldn't be reading and considering every proposal that is submitted according to the correct procedures? So how should they filter them? Ask you and see if you give the thumbs up?

1. Completely failing to understand _practical_ matters.

Says the person who believes that by magic the C++ committee can make everyone switch to a new, incompatible language and avoid fragmentation! That's about the biggest practical matter and you claim outright that it doesn't exist. Then you rather hilariously accuse me of not understanding the practicalities.

OK, smart-ass, how would you force everyone to switch to a future non-backwards compatible version?

2. Continue to make excuses for why their tools are crap.

Tools are crap for reasons you haven't mentioned: namely it's sodding hard to parse C++. Because of (1) the committee can't fix that. But again, the OP complained that the "committee have their heads up their asses", which is a foolish and ignorant statement. There hasn't ever been a language standard which specifies the kind of tooling he was asking for.

And tools have nothing to do with the language standard.

3. And then post blatantly false information that gets modded up to Insightful without a clue.

Except nothing I said was false.

Scools and education are mighty bizarre places.

There's weird emphasis on useful things except where there isn't.

No one pretends that literary criticism is a useful skill, or that reading books is anything other than entertainment. Yet it is taught. Likewise, History is only needed if you're going to teach history, but it's taught because knowing history is part of being a well rounded person.

Apparently things that can be technical have to be useful.

Personally I think programming should be taught in schools along with maths, English, history, "building stuff" (DT in the UK), sciences, foreign languages and etc.

Not becauese is useful.

It should be taught, like the other subjects because it is interesting and can teach one to think in new ways that other subjects don't teach---just like all the other subjects[*]. Not everyone will like it and some will and most won't go on to use it. But writing is taught even though most people woll never go on to write a book.

[*] It's arguable that the other subjects do that, but that has more to do with how badly the subjects are taught than anything inherent to them.

Odd. In my experience, the people who insist you need a 'special mind' to code are deeply insecure people with no other skills.

eh. I think one does, but not in the way many people mean. I think "young" or "not already messed up" is the specialness required. An alternative interpretation is that "special" means "attuned to the way most teaching is done". If of course you only do teaching in that way then it tautologically does in fact require a special mind.

At school (age 13), my school rather unusually had programming classes in BBC Basic. Most people were crap but almost everyone was able to get a basic text based adventure up and running. In other words, more or less everyone was able to write some really simple code of their own.

Fast forward too many years to when I was teaching programming to undergrads.

Some of the students, who were orders of magnitude smarter that the people who managed basic programming in my school by almost any way of thinking really, really, REALLY struggled. What seemed to be the problem was that any high level language requires an awful lot on trust. Some of those sutdents responded much better to ASM programming, especially given a databook which documented every aspect of the microcontroller in incredible detail. Once that was sorted, explaining a higher level language in terms of how it would translate into ASM seemed to be very helpful.