LWN.net comments

Numerous security issues in X Window System clients

dlang — 2013-05-25T00:49:31+00:00

Every replacement system performs better when it's first introduced. It's simple and doesn't yet take into account all the real-world corner cases that users run into.

the question is how much do things slow down by the time they are really ready for users. Is the result really still a lot faster than the old system (which may have picked up some optimizations along the way)

There's also the question of if the difference in speed matters.

shaving 0.1 sec off of a one hour job makes no difference, even if it saves 99% of the time that one particular function takes.

in some cases, it's comparing apples to oranges, for example, see the raspberry pi post where they introduce wayland for the pi and crow about how much faster it is. It's faster because the wayland implementation does the acceleration in the GPU while the X implementation does it in the ARM core. If you were to update the X implementation the same way, the difference would shrink drastically.

Debian GNU/Hurd 2013 released

marcH — 2013-05-25T00:30:07+00:00

> I really don't care what kernel it uses. And that has little to do with the licensing [...] It's about quality and consistency. GNU makes the best userspace, IMO.

Wait, let me guess... then you must belong to this strange species called... "users"? :-)

Until a few years ago there was still a "risk" that non-geeks confuse Linux and GNU userspace. Android/Linux is so different and now so popular that I think this risk is mostly gone.

So, does Richard feel better now? Maybe not...

An unexpected perf feature

ras — 2013-05-25T00:21:13+00:00

> P.S. I disagree with you about the Itanium. It wasn't a good design. They took far more silicon than other processors and ended up being less productive with it.

I wasn't commenting whether it was a good design. I don't know, as I haven't used it. I was just saying Itanium marked the point when Intel went back to sticking to the knitting - in other words trying to design a new architecture whose sole goal was to run programs fast. If you say they failed despite having that explicit goal then that's a shame.

As I recall the Itanium tried to improve it's speed in a RISC like way - ie by keeping things simple on the hardware side and offloading decisions to the compiler. In the Itanium's case those decisions were about parallelism.

I think it's pretty clear now tuning the machine language to whatever hardware is available at the time is a mistake when you are going for speed. It might work when the hardware is first designed, but then the transistor budget doubles and all those neat optimisations don't much so much sense anymore, but you are welded to them because there are hardwired into the instruction set. Instead the route we have gone down is to implement a virtual CPU, rather like the JVM. The real CPU then compiles the instruction set on the fly into something that can be run fast with todays transistor budget. With tomorrows transistor budget it might be complied into something different.

The x86 instruction set is actually good pretty in this scenario - better than ARM. It's compact, and each instruction gives lots of opportunities to execute bits of it in parallel. If this is true, then Intel ending up with an architecture that can run fast is just dumb luck, as they weren't planning for it 30 years ago. Now that I think about it, the VAX instruction set would probably be even better again.

Numerous security issues in X Window System clients

butlerm — 2013-05-25T00:10:34+00:00

> Because it's still useful in many cases (e.g. between machines on the same LAN) to run remote X clients over an SSH tunnel.

That is why you would dynamically load it - use a library derived from the X server code to draw into something like a Wayland frame buffer when local, and use the X wire protocol when using an X server over a network connection. As long as you are on the same machine, a large class of X applications should run much faster, with a higher degree of security, and so on.

Even without a compositor, this is arguably the way it should have been done from the beginning. What is the point of protecting access to the frame buffer on a typical embedded system? It just slows things down.

An unexpected perf feature

dlang — 2013-05-24T23:50:41+00:00

> 8086 actually. It was their way of extending the address space of the 8080 to 20 bits.

That's right, I forgot about that. And IIRC, with the 286 they only expanded it to 24 bits

but in any case, my point was that the dawn of the AMD64 chip is eons past the point where segmentation was introduced, failed, and was rejected

P.S. I disagree with you about the Itanium. It wasn't a good design. They took far more silicon than other processors and ended up being less productive with it.

In part, the speed increases were the cause of this failure. As the speed differences between memory and the CPU core get larger, having a compact instruction set where each instruction can do more, becomes more important, and for all it's warts, the x86 instructions do rate pretty well on the size/capability graph.

but in part the programmers really should NOT have to change their programs to work well on a new CPU where the hardware designers have implemented things differently. By hiding such changes in the microcode, instructions that get used more can be further optimized, and ones that aren't can be emulated so they take less silicon. It's a useful layer of abstraction.

How Google plans to rule the computing world through Chrome (GigaOM)

dlang — 2013-05-24T23:39:46+00:00

you have no more right to criticize them for using their language of choice than they have a right to criticize you for being 'old fashioned' and using your language of choice (be it C, Java, or whatever)

or for you to criticize them for what type of shoes they wear (or don't as the case may be)

If your favorite language falls out of favor, find another one that you like and learn it.

No language has, or will, ever succeed in completely replacing the 'preceding' languages. There are still good jobs programming in Fortran and Cobol for crying out loud

Trying to prevent other people from spending their programming time the way that they want to (or the way the people who pay the bills want to) borders on "Evil"

You really don't want that sort of power to exist, because fads change and someday you will be in the minority and people will wish your language would just go away.

Remember how Linus was told that he was wasting his time writing Linux? that "everyone" knew that monolithic kernels and Unix were obsolete? what if they _could_ have prevented him from continuing to work on it?

An unexpected perf feature

ras — 2013-05-24T23:31:43+00:00

> segmentation on the x86 came about with the 80286 (or possibly even the 80186, I'm not sure) CPU.

8086 actually. It was their way of extending the address space of the 8080 to 20 bits.

It was just a slightly more sophisticated take on the way CPU designers have gone about extending the range of addressable memory beyond the natural size of internal registers for eons. It had the advantage you could use separate address spaces for both code and data, giving you 64K for each. So by using a small amount of extra silicon they effectively doubled the amount of address space you had over simple "page extension" hack everybody else was doing. Kudos to them.

So you are saying it was the 80286 is where the rot set it. In the 80286 they had enough silicon to give the programmer true isolation between processes. They could of gone the 32 bits + page table route everybody else did, but no we got segmentation (without page tables instead) and retained 16 bit registers. Why? Well this was also the time the hardware designers had enough silicon to implement microcode - so they could become programmers to! And they decided they could do task switching, ACL's and god know what else better than programmers, so they did. In other words somehow they managed to forget their job was to provide hardware that ran programs quickly, and instead thought their job was to do operating system design.

It was a right royal mess. Fortunately for them the transition from DOS to Windows / OS2 (which is where the extra protections and address space matters) took a while, and by then the i386 was released. It added 32 bits and paging, so we could ignore all that 16 bit segmentation rubbish and get on with life. It turned out the transition to multitasking operating systems wasn't waiting on programmers figuring out had to do it (who would have thunk it?), but rather the price of the RAM needed to hold several tasks at once had to come down.

People here defending the segmentation model should try writing for the 80286, which could only address 64K of code and 64K of data at any one time. There was no reason for it. The 68000 family had a much better memory model at the time, so it wasn't silicon constrains. Well there would have been enough silicon if they hadn't devoted so much of it to creating their own operating system on a chip.

Intel finally came to their senses with Itanium. With it they used all that extra silicon to do what hardware designers should be doing - make programs run fast. Sadly it came along too late.

Back to your point - the time line. The 80286 was released in 1982. The iAPX432 was meant to be released in 1981. The 80286 was the fall back position. As Wikipedia points out, this is a part of its history Intel strives to forget. You will find no mention of the iAPX432 on their web site, for instance.

Numerous security issues in X Window System clients

rqosa — 2013-05-24T22:59:41+00:00

> Why wouldn't we just have Xlib or XCBlib or whatever dynamically load a library that implements X in process then, instead of engaging in relatively pointless IPC?

Because it's still useful in many cases (e.g. between machines on the same LAN) to run remote X clients over an SSH tunnel.

How Google plans to rule the computing world through Chrome (GigaOM)

smokeing — 2013-05-24T22:48:46+00:00

> nobody is asking you to write or modify core chromebook code
Yeah, thanks for clarification.

But no, I do take an issue with proliferation of code written in JavaScript. I am, these very days, being furious at having to change jobs a second time in half a year, for the reason that the code I had to deal with was crying for one thing: total deletion, whilst my job was to fix it. I'm just giving up. Ok, it wasn't JavaScript, but my argument still stands.

> Being picky about what languages you use is perfectly fine
I am being picky precisely with languages others use.

Ten minutes spent necessarily daily in casual company of PHP/JS developers A and B gets me nervous and excited for all the wrong reasons, such that I seek an hour every other week to hang out with Erlang developers C and D. With A and B coming in numbers --and C and D just getting old and grumpy-- I feel somewhat of an endangered species myself.

NetBSD 6.1

Cyberax — 2013-05-24T22:48:11+00:00

Sure. But sometimes there ARE significant differences and it's interesting to check why.

Besides, you're inconsistent with nix - his gripe is that Phoronix also uses complex tests that stress various parts of the system :)

NetBSD 6.1

lsl — 2013-05-24T22:43:56+00:00

> You might also note, that they ALSO test pure CPU-bound tasks.

Yep, they do. They use them to show that GNU Hurd is just as fast as Linux. Compute-bound numbercrunching software seems just the right stuff to measure performance differences between different kernels.

Google Code to deprecate downloads

rleigh — 2013-05-24T22:41:07+00:00

"Git is easy once you understand how it's built. It's just a chain of diffs linked by their SHA1 hashes - everything else stems from that."

Sorry for the pedantry here, but the git model is the exact /opposite/ of a chain of diffs. It is blobs, trees and commits. From the chain of commits, deltas can be computed between the trees /if required/, but diffs are not part of the model. RCS, CVS, Arch, etc. are all based around chains of diffs, and much of the power of git stems from rejecting this model, since it's extremely inefficient, and writing algorithms to work on it is conceptually much harder. Internally, the git packfiles can deltify objects for space efficiency, but that's purely an internal implementation detail which the git user need not care about.

Regards,
Roger

An "enum" for Python 3

flewellyn — 2013-05-24T22:36:33+00:00

Why do we want enums, instead of symbols?

Perhaps being able to create a type which is a "symbol class", where each of its members is a symbolic constant that evaluates to itself, would solve the issue? Particularly if two symbols only compare equal if they are literally the same, i.e., the same symbol class member.

For instance:

class Color(Symbol)
red
green
blue

And then this would work:

isinstance(Color.blue, Color)
=> True

And this (for some pixel object):

pixel.setColor(Color.blue)

pixel.getColor() == Color.blue
=> True

But if you had this:

class Animal(Symbol)
cat
dog
elephant

Color.green == Animal.dog
=> False

Seriously. Enums are a hack for languages that don't have symbol types. Why not do things RIGHT?

Password scheme

diederich — 2013-05-24T21:54:47+00:00

Selecting at random four words from the /usr/share/dict/words on my box (which contains 99171 entries) gives you more than 64 bits of entropy. At one billion tries per second, it will take up to 584 years to find the right combo.

You did say 'reduce'; most people select passwords that have less entropy, and are possibly not as easy to remember.

I'm not aware of any system that allows me to remember that many bits of entropy so easily.

Google Code to deprecate downloads

Cyberax — 2013-05-24T21:16:19+00:00

You typically need only the first 4-6 letters of the hash which is less than a typical revision number in SVN.

Besides, hashes is the only natural way to represent a code revision in a truly distributed system. Everything else are just attempts to paper over the distributed nature and they leak at most inappropriate moments.

Google Code to deprecate downloads

rahulsundaram — 2013-05-24T21:15:24+00:00

Your request for "factual" arguments is amusing. Let's inject some facts for the first time in this conversation then:

If was designed to be harder to use and wasn't more powerful, it wouldn't be the most popular dvcs. Would it?

The real reason why it was more harder to use originally had nothing to do with geek credence but simply because it was designed by a kernel developer to satisfy his needs and as soon as it was usable enough for him, he handed it over to a different maintainer who has made it substantially more usable while retaining the performance and power advantage that git has always had over other tools.

Btw, bazaar is mostly unmaintained these days with Canonical pulling off its investment and it has thousands of open and unanswered bug reports last time I checked. Mercurial is a reasonable alternative though.

Google Code to deprecate downloads

Baylink — 2013-05-24T21:12:06+00:00

Well, perhaps that's the problem.

I have the perception that one *must*, rather than merely "may" interact with git using those big long ugly hashes.

Google Code to deprecate downloads

Cyberax — 2013-05-24T21:06:56+00:00

Git is easy once you understand how it's built. It's just a chain of diffs linked by their SHA1 hashes - everything else stems from that.

For example, merge is simply linking two hash chains. Fast-forward is just appending new diffs on top of a hash chain. Rebase is editing one or more diffs in the middle of a chain, which causes all the upstream SHA1 revisions to change. Etc.

Git command line set, on the other hand, is atrocious.

dedent

deunan_knute — 2013-05-24T21:02:28+00:00

scala has a nice method called stripMargin which is similar to textwrap.dedent. it strips leading whitespace from a triple-quoted string, up to and including a separator character (by default '|'). with the separator, you don't need to worry about 'common whitespace', which may be difficult to visually distinguish. it's not a python solution obviously, but seems trivial to add the separator functionality.

the one downside of dedent is you have to evaluate everytime you want the string. however, i think the only time i used concatenated strings in C was when formatting a help string, which is not exactly a critical path.

Google Code to deprecate downloads

Baylink — 2013-05-24T20:58:50+00:00

It is clear -- since git was by no means the *first* DVCS -- that there are other ways to do that work. So if git is more complicated to understand and use (and there are lots of reports that it is) and there isn't a concomitant increase in power and utility (and there are enough reports that there is not), then I have to look elsewhere for reasons why a) it would be designed that way and b) it would be more popular.

Geek hubris (and the fact that the kernel is maintained in it :-) are all I can come up with, but I invite factual counterarguments.

Google Code to deprecate downloads

rahulsundaram — 2013-05-24T20:40:07+00:00

Git is the most popular dvcs by a fair margin. While there are many users who might find it hard to use a particular piece of software but a claim that it was *designed that way* is nonsensical.

Google Code to deprecate downloads

Baylink — 2013-05-24T20:16:51+00:00

Concur; bzr was my first dvcs, and I had no trouble figuring out how it worked. Git, on the other hand, either a) I am too old for or b) was designed specifically to be hard to understand, as geek leetness.

Numerous security issues in X Window System clients

jg — 2013-05-24T16:33:52+00:00

All I can say is that in 1984-1988 it was a very, very different world. We're talking about > 25 years ago; many LWN readers weren't born then.

There weren't bad guys out there. I remember the Morris worm hitting when I was working on the X11 protocol bindings. And Kevin Mitnick had just reared his head a year or two before.

Some of the bugs I clearly wrote in that period, and others copied my mistakes (and clearly made more of their own). Others of the just couldn't happen in practice on machines of that era (say, 2 megabyte MicroVax's).

And X is still used widely remotely: just usually via SSH tunnels.

But the case you really worry about is different: remoting you application to an untrusted/untrustworthy X server, which may want to break into your machine/device. This is still a thing of desire (but SSH has highly discouraged this capability). So these problems, in practice, don't happen much.

I'm still happy to see the bugs get fixed, of course.

Numerous security issues in X Window System clients

Wol — 2013-05-24T16:12:14+00:00

And remote X is still used today - I use it!

It's a great way for repurposing old hardware, I use it as an X-terminal while my wife is on the main machine.

The big pain is the Cygwin X server (on Win 7) does not seem to work very well at all.

Cheers,
Wol

Name

zonker — 2013-05-24T13:57:05+00:00

I think the name is intentional, though. I've been informed that "Qt" is supposed to be pronounced "cute" so what you have is "Boot to Cute."

An unexpected perf feature

dlang — 2013-05-24T13:40:45+00:00

you aren't going nearly far enough back

segmentation on the x86 came about with the 80286 (or possibly even the 80186, I'm not sure) CPU.

It was intended as a way to allow programs to continue to use 16 bit 8086 addressing but be able to use more than 64K of ram in a system (by setting a segment offset and then running the 16 bit code inside that segment)

It never was an effective security measure, because to avoid wasting tons of memory on programs that didn't need it, the segments overlap, allowing one program to access memory of another program.

When the 80386 came out and supported paging and real memory protection, everyone stopped using segments real fast

x32 ABI support by distributions

deater — 2013-05-24T13:18:02+00:00

> In fact arm64 is not a traditional RISC instruction set like PPC,
> mips, sparc :
> - the instruction size is 32 (and not 64 bits)
> - it works on 32 or 64 bits data
> - register/instruction are different between native 32 bits
> mode and 64 bits mode.

As far as I know there aren't any RISC chips with 64-bit long instructions (if that's what you mean). Usually they are fixed 4-byte (32bits).

Also the 64-bit RISC chips can operate on 32-bit (and smaller) values just fine. If you mean you can't operate on the bottom 32-bits with ALU instructions while ignoring the top 32-bit, that might be true.

I'll give you the last point though. ARM is unusual in that the instruction encoding is completely different between 32 and 64-bit. Even x86 didn't go to that full extreme

Anyone remember Qtopia?

tsdgeos — 2013-05-24T13:13:56+00:00

This is not a project of the Qt community but a project from Digia, and from reading the blog i understand it's a non free.

An unexpected perf feature

helge.bahmann — 2013-05-24T12:43:55+00:00

Sparc has instructions "load from foreign address space" and "store to foreign address space" (and even "compare and swap in foreign address space").

An unexpected perf feature

ras — 2013-05-24T12:00:39+00:00

As a "bearded guy" (I have no beard) who has written designed and written bios's and protected mode operating systems x86, and who had to look at the x86 architecture in detail again in mind numbing detail (as in reading the 4 Intel x86 "data sheets" several times in order to port linux-abi system to AMD64), I recall my thoughts at the time as being "my - AMD has cleaned this mess up".

For those of you defending Intel's decisions at this time - I lived through it. At the time Intel regarded all programmers as idiots, and decided to solve the problem with hardware. Thus we have the absurdly complex designs we see today, with x86 interrupts taking 2000 cycles (?!?!? - that was back when Intel was game enough to publish cycles) and it wasn't the slowest instruction. Can anyone remember a Task Gate Descriptor?

Yet that wasn't the worst of it. The worst of the worst died. It was a new Intel architecture called iAPX432. It caused more excitement than Haswell in it's day. I am sure it's forebears would prefer we forgot it entirely. It remains in my mind the ultimate testimony to the arrogance caused by ignorance, in this case the Electrical Engineers thinking they could tell Software Engineers how we should do our jobs. But I exaggerate. Back then we weren't allowed to call ourselves Engineers.

Still they got their revenge with x86. In it they made it plain we could not be trusted to swap between two tasks quickly. Only 30 years later with the advent of ARM has their folly been made plain to everyone.

Numerous security issues in X Window System clients

ajmacleod — 2013-05-24T11:21:01+00:00

Re: Fran Taylor -- What complete nonsense. Remote X has worked remarkably well for decades and is incredibly useful and flexible. No doubt it harks back to an era where security was less of an issue but still today in the real world it just gets the job done, limitations accepted and understood.

I really wish the clueless idiots who don't understand or use this flexibility would stop shouting loudly about X being a worthless disaster with remote display abilities that nobody uses when these same abilities have been making life simple for so many people for such a long time; we don't usually shout about that because we've taken it for granted for so long.

DeadDrop and Strongbox

ras — 2013-05-24T10:41:34+00:00

So this will be the legacy of Julian Assange. To show the world how it could be done, but perhaps not how not it should be run.

That is enough I think. Well done Julian.

Unsure whether this is good or bad

edeloget — 2013-05-24T10:39:51+00:00

But then, as you say, you can't provide any rpm, deb... to your users (unless you store them elsewhere - GDrive or any other host will do fine).

Being able to download the source as an archive is of interest, but then most of the time the distributed source can differ from the git tree (especially if you plan to deliver a configure script instead of a configure.ac file). You may also want to autogen your ChangeLog from your git history... So proposing a source tarball which is not identical to your development tree makes sense (and not being able to store both at the same place doesn't make much sense).

Now, the feature cannot disapear completely and you can recreate it quite easily. Create a new git repo download (administer, source), and push your tarball there. Add a link (administer, project summary) on you mainpage to the branch itself and voila. You also have to explain to your users how to download a file from this new git repo (a bit more convoluted than the plain old download).

For scripters, wget https://PROJECT.googlecode.com/git/PATH/TO/FILE will be goog enough.

Next week's edition will be published on May 31

ras — 2013-05-24T10:35:21+00:00

So the delay will be caused by will be sushi and sake instead?

Cheers!

A look at the PyPy 2.0 release

zack — 2013-05-24T10:31:44+00:00

> Getting PyPy 2.0 is a bit tricky, at least for now. Those who are on Ubuntu 10.04 or 12.04 can pick up binaries from the download page (as can Mac OS X and Windows users). While many distributions carry PyPy in their repositories, 2.0 has not arrived yet.

FWIW, on the very same this article went out, PyPy 2.0 has been uploaded to Debian unstable http://packages.qa.debian.org/p/pypy/news/20130515T180110...

Call it a race condition :)

An unexpected perf feature

helge.bahmann — 2013-05-24T09:16:39+00:00

Just as an addendum... Don't get me wrong, you are right to complain that a mechanism that was usable for security purposes was removed while nobody bothered to add a suitable substitute, and that all of the pretty architectural ideas that had already been present and demonstrated to be workable for 25+ years now had been ignored, but the "proper" way going forward is not to revive segmentation but implement comparable semantics with mechanisms that are performance-neutral. SMEP and SMAP are actually quite "easy" from a hardware conceputal point of view, so it is kind of annoying that it took so long.

An unexpected perf feature

helge.bahmann — 2013-05-24T08:53:31+00:00

1. Sure it's not a single 80s style alu anymore, rather it is a set of independently operating arithmetic units; typically two are adders, and whatever is needed is scheduled to them (addr gen or general arithmetic alike). Doing anything else is wasteful (which is to say that it is done nevertheless occasionally *if* it can speed up a fast-path, which for address calculations it cannot).

2. TLS is not a fast path, profiling shows around 1 in 1000 to 10000 instructions is TLS, so no one bothers paying a 1 cycle penalty for that.

3. ASIDs are cheaper because they just become part of the tag in the TLB. You do the TLB lookup (which you do anyways) and compare the tag for equality which is cheaper than a "greater than" comparison against an address space limit (which, incidentally, is just another adder), end of story.

4. Enforcing read-only is easily done at the page level, so what's the point?

5. What segmentation has been designed for? To map the concept of program object segments (the name may be a hint, right?) directly to hardware, facilitate sharing and relocatability this way. This is also where the security model for them originates from. It was conceived when people were somehow not yet certain paging was scalable, but I am too young to have been involved back then, you would have to ask the 'bearded guys'.

And to answer your last question: Paging is cheaper because hashed lookup (TLB) and equality comparison are cheaper than "less than" comparisons in hardware. Segmentation is a conceptual dead-end, live with it :)

x32 ABI support by distributions

Matc — 2013-05-24T08:52:50+00:00

> Doing this with ARM will be a hassle

Arm have the same problem than x86 : arm64 is completly different from arm (32 bit).
It is new instruction, different registers, ...

But because arm64 have instruction for working on 32bits or 64bits data/register, it should be easy to do something like x32 on arm.

In fact arm64 is not a traditional RISC instruction set like PPC, mips, sparc :
- the instruction size is 32 (and not 64 bits)
- it works on 32 or 64 bits data
- register/instruction are different between native 32 bits mode and 64 bits mode.

Debian GNU/Hurd 2013 released

drothlis — 2013-05-24T08:29:05+00:00

No point; it was a complete tangent. I genuinely wonder how hard it would be.
GNU Make seems like a significant piece of software but at the same time very
self-contained and conceptually quite simple.

What I want from a make implementation:

+ Parser accessible as a library (for IDEs, static analysis tools, etc).
+ Be able to switch features on and off; issue warnings if a makefile uses
a particular feature.
+ Well-documented source code; easy to implement new features.

Does Tickless supports for Octeon-2 and ARM as well ?

ajaycavium — 2013-05-24T07:56:51+00:00

Can anybody please tell this feature is supported for Octeon-2 and ARM as well or it is for x86 only.

An "enum" for Python 3

jezuch — 2013-05-24T07:49:03+00:00

> You could make enums an intrinsically unnumbered type, or a type whose numbering is hidden and could not be specified at all, but it would drastically limit their usefulness

Or you could allow enums to have members - fields and methods - and provide the conversion yourself when needed. You could also add some syntactic sugar for the common case. That's one of the great things about enums in Java - they are almost-regular classes, so they can engage in (interface) inheritance and polymorphism at will. Oh, and you can switch() on them ;)

An unexpected perf feature

dlang — 2013-05-24T07:48:47+00:00

if they were so fully separated, how could you pass data between them?

Even if true, it just shows that price and performance trump low probability security benefits once again, so what's new?

An "enum" for Python 3

mgedmin — 2013-05-24T07:46:12+00:00

Heh. I got into the habit of using print("one value only") to be compatible with Python 2 and 3 at once, without a __future__ import. And then I discovered that print() is also valid in this mode, but does something completely different on Python 2. ;-)

All my blank lines became

()

An unexpected perf feature

ballombe — 2013-05-24T07:35:04+00:00

From a security point of view amd64 _is_ bad, especially compared to older architecture like sparc which provide fully separated kernel and user address space.

Numerous security issues in X Window System clients

ortalo — 2013-05-24T07:28:48+00:00

Entirely agreed. I'd go even further: these classes of vulnerability probably still exists in other big pieces of software not as well scrutinized as the major ones. Such examples should make us worry much more about our database clients, our spreadsheets, our mail clients, etc.
Fortunately for open source, these examples give us even more inspiring ideas about the situation with proprietary or industrial software...

Numerous security issues in X Window System clients

renox — 2013-05-24T07:27:03+00:00

> Ok, let me paraphrase: modern X windows applications mostly does not use network for drawing ;)

You're doubly wrong:
1) you can configure KDE|Qt to use XRender.
2) as Cyberax said, even the oldest "draw stipple line" that noone use are still part of the protocol, of course this matter more for the server than for the clients.

Numerous security issues in X Window System clients

geofft — 2013-05-24T07:02:02+00:00

What does this have to do with the network, at all? It's about a binary protocol between two components of different privilege. The same class of vulnerabilities could as well exist in D-Bus, in the Windows syscall API, in packet filtering, in communication between Chrome and its tabs, in SATA or SCSI or Android intents or systemd talking to services -- nothing here is specific to X being on the network.

And fundamentally, this entire class of vulnerabilities could equally well exist in every single other display architecture, even though they don't use "network" connections.

Numerous security issues in X Window System clients

butlerm — 2013-05-24T06:58:30+00:00

> Yep. Having a private X server for each application is also an interesting idea.

Why wouldn't we just have Xlib or XCBlib or whatever dynamically load a library that implements X in process then, instead of engaging in relatively pointless IPC? The lower level server would be handling all the compositing and arbitration.

Numerous security issues in X Window System clients

micka — 2013-05-24T06:51:51+00:00

> I'm waiting to see how Wayland protocol will look like and behave after 20 years...

You'll just have to wait 20 years.

Name

epa — 2013-05-24T06:09:13+00:00

They missed an opportunity to call it Bt to Qt.