Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?

Comment Re:Almost as if (Score 1) 127

You know, you touch on something that bugged me when I watched the Iron Man movies. Where is the reaction mass for Iron Man's flight coming from? Even a lightweight, unlimited power source wouldn't solve the problem of reaction mass. The Iron Man suit obviously uses some kind of reactionless drive -- not inconceivable, given that it also has "repulsor" technology which has no plausible physical explanation and violates classical physics.

The arc reactor idea actually is interesting to think about. Suppose you had an unlimited energy source with negligible weight. Could you build something like a rocket belt? I think you could, say by driving a turbine or some more exotic method of accelerating air. Technically it wouldn't be a "rocket" belt, but it would fit the bill. Even you'd still be limited in how small you could make the thruster due to the hazards the high velocity of the exhaust would present to the user and the surroundings.

Comment Re:What is "computer-directed flight control"? (Score 2) 353

Well, electrical, mechanical and electro-mechanical analog computation was a hot research in the 30s and 40s. People forget that "op-amp" (invented in 1941) stands for "operational amplifier" -- a device originally intended to do analog integration.

The fire control computers on WW2 naval ships were highly sophisticated electromechanical computers, although obviously too large for an airborne system. On the other hand the contemporary Norden bomb sight was, in effect, a compact, specialized analog computer.

The idea of connecting such a system directly to control something directly would have been very advanced for its time. Cybernetics as a practical discipline was in its infancy. I suspect the "computer-directed flight control" refers to flight surfaces that are automatically adjusted based on several user inputs such as throttle and yoke. This is the kind of thing that would be handled by a computer in a modern high performance aircraft, or by some complicated manual procedure in a racing aircraft of the era. That woudl arguably a kind of special purpose computation although calling it a "computer-controlled flight controller" would be a stretch.

Comment Re:Almost as if (Score 1) 127

Jet packs make sense if you can get them to work.

There's the rub right there. Feasibility is a prerequisite of "making sense", and in the real world you have to deal with physics and the physical limitations of human beings. Antigravity would "make sense" if you could get it to work.

The physics of a jet pack are governed by the rocket equation: V = Ve * ln(Mt/Mp). You need to carry enough mass, ejected at a sufficient speed, to produce 9.8 m/s v every second.

The upshot is that to counterbalance the weight of a soldier and his gear you can either have your rocket eject a lot of mass at low velocity or a small amount of mass at high velocity. That's why the rocket belts thus far have only had a very, very short burn time. To increase the burn time you'd need to carry more fuel than a man could lift.

A typical infantry solider or marine carries over a hundred pounds of gear into battle. Even accounting for things he could dispense with if he had greater mobility, he can't carry much fuel to power his rocket belt. A practical battlefield air transport machine would be a small vehicle which carries more weight than an individual solider can. In other words: a helicopter.

Similar concerns attach to asteroid mining. You *can* physically go out there and return materials from asteroids, just like you *can* strap a rocket belt on a soldier. The question isn't whether physics permits it, but rather whether physics permits economically feasible retrieval of asteroid material, and that's a lot tougher than it sounds. Even the "asteroid belt" is practically empty by terrestrial standards; your chance of randomly encountering anything larger than a dust speck while crossing it is less than hitting the lottery. So prospecting for nuggets of stuff like platinum is physically possible, but not feasible. Unless we hit the jackpot with a near earth object like 433 Eros, we won't see asteroid mining until v in space becomes much, much cheaper.

Comment Re:The primitive division of both sides is appalli (Score 1) 479

Why couldn't Ukraine become a model of a bi-ethnic state? Russians and Ukrainians are so similar.

There's your answer right there.

It's a bit like the uncanny valley. People who are very different from you are interesting and exotic; you know it takes some effort to understand them. People who are just a little bit different from you are too incorrigibly stubborn to bring themselves up to snuff and think and act the right way.

That's why civil wars are so bitter and inhumane. In some ways it's harder to see humanity in someone who is culturally similar but irreconcilably different than in someone who is alien. Rudyard Kipling could wax lyrical about the noble savages in "Gunga Din" and "Fuzzy-Wuzzy", but he never once penned a poem in praise of the Liberal Party.

Comment Re:"pro-Russian forces in Crimea" (Score 1) 479

and now let's talk about the leaked documents involving the "pro-western forces in the Ukraine""

OK, lets. The US government is far from lilly-white, but if it and allied governments were coordinating violent opposition to the Ukrainian government too, that would surely be in the cable leak.

Comment Re:By first throwing out. (Score 2) 195

Which fits with something which characterizes most effective sorting algorithms: they get rid of a lot of entropy early on. This works for tidying the house too. Start by throwing out stuff, then by moving things to the room they belong in, then putting them away.

To answer the question, I tend to quick sort things into manageable unsorted piles, insertion sort the piles and reassemble the piles.

Comment Re:Could somebody explain wayland, please? (Score 2) 77


Thank you for the additional details. You are right -- I meant to make it clear that the Wayland design was thought up by people with some serious experience of the internals and limitations of X, and not a competing team of newcomers, as appears to be assumed all too often. But yes, things aren't as simple as I made them look and there is only a partial overlap between the Wayland devs and the Xorgs devs. Thank you for the correction.

I also agree that Wayland is largely about canning the legacy in order to make current and future needs easier to tackle.

I don't agree with your opinion of the move as a technical choice, though, for three reasons.

1/ Taking X out of the rendering loop does not mean dropping X altogether. It just means that future X servers, when and where they are still needed, will run on top of Wayland. It does deprecate X as the default API, yes. But that's not remotely the same as breaking compatibility.

2/ The comments that Daniel Stone (core Xorg and Wayland dev) made in that oft linked video aren't in agreement with the idea that everything Wayland does can be done on top of X, let alone done well. In his talk, DS mentions e.g. issues with input management when one window wants to grab every input that can't be solved in X.

3/ As a more general philosophical principle, the world moves and everything changes. Everything has a shelf life, up to the universe itself, and there is a point where resisting change for the sake of keeping past things going becomes harmful. And this is the actual reason I've been so active in this thread. Not just because I've got a pretty good hunch that once the dust settles Wayland will largely work better than X. But because I think that we, Slashdotters, Linux users, geeks and nerds, are becoming fearful of change, and that's not a good thing. This, here, is an entire new toy and it opens entire new possibilities! It may break shit and it may be awesome and it will probably be a bit of both. Let's freaking check out the code and play with it! Is this not exactly what we should be about? :)

Have a safe flight, and thank you for the constructive reply!

Comment Re:Tim Cook doesn't understand the Law (Score 1) 348

Well, I think it's safe to say that the vast majority of shareholders in a joint stock company are at least *primarily* motivated by profit. But investors differ from each other in their temperament and priorities, otherwise there wouldn't need to be a stock market. Everyone would by the same stocks.

One of the big differences that drives investment choices is your investment horizon. If you're focused on return in the next quarter or two, you'd act precisely as this guy wants Apple to act. If it's not generating ROI in the next year to eighteen months at at least normal profit rates, you don't do it.

But the farther out your investment horizon is, the further into the future you are planning on holding a stock, the more differences in your beliefs and expectations about the future are going to differentiate you. Green energy is a good example. If you're investing for the next year or so, supporting green energy initiatives would be an act of altruism. If you are investing for the longer term you may see it as a hedge against future price volatility in fossil fuels -- presuming you *anticipate* future volatility, not everyone does.

Investment isn't just a numbers game; it's a belief about the future game. The longer the investment horizon, the more your individual beliefs about the future play in what courses of action you think will maximize profit.

Comment The author ought to have a nice cup of chamomile. (Score 2) 794

He gets all wrought up over things like Ezekiel bread, as if it were some kind of plot to slip Christian doctrine into us via our alimentary canals. In reality it's no different from Dogfish Head's line of historical beers. People buy them for the interest value. And most people who buy Dr. Bronner's soap because it smells nice; the gibberish on the label only gives you something to read in shower.

The issue with probiotics is that the food industry has got ahead of the science -- as usual. This kind of thing is everywhere you look. There's a difference between making scientifically unproven claims and claims that are actually *against* science. Once you discard the insufficient evidence stuff and the stuff that is meaninglessly vague, you're pretty much left with nutritional supplements and homeopathic nostrums, which are sold everywhere. "Insufficient evidence" and "meaninglessly vague" cover practically *everything* sold that makes some kind of health claim, right down to low fat milk which has been sold for its health properties for fifty years with no supporting evidence.

What Whole Foods is, is not a health food store; it's a high end grocery chain. Just look at their cheese department. Whole Foods is to the old time city gourmet food shop what the modern supermarket is to the neighborhood grocery store. It caters to high incomes. The health food thing is part of the clever packaging, like the high color temp lighting in the stores. It's meant to evoke the kind of food co-op many highly educated people may have shopped at in their college or graduate student days, but it's selling convenience packaged foods, not bulk.

Comment Re:Could somebody explain wayland, please? (Score 1) 77

> Nobody uses Weston so the fact it has RDP support is dick all use to anyone using GNOME or KDE.

Ding ding ding. This, here, is what I think is the main problem with the Wayland ecosystem as it currently exists.

As things currently stand, the Wayland protocol is designed to give compositors a lot of flexibility in what kind of buffers they support, with what capabilities.

The drawback is fragmentation.

So okay, the Unix world at large is not a newcomer to fragmentation issues. But it's still a problem that will have to be addressed.

As I said in another comment, I think that things will probably converge on the common ground of either a de facto standard compositor, or a set of common libraries. Wayland itself will probably ship with a generic, non-optimized implementation for common capabilities like remoting.

But until then, it is an issue, and it would be dishonest not to acknowledge it.

Comment Re:Could somebody explain wayland, please? (Score 1) 77

> It will, however suck just as hard as all the other pixel-scrapers.

You are doing the same thing again.

You are asserting, without proof, that Wayland remoting will necessarily have to work as a pixel scrapper.

Wayland is designed to be extensible with regards to supported buffer types. For instance, YUV video buffers were merged into the reference compositor at some point in 2012.

And remoting specific buffer types can be done vastly more efficiently than with a generic pixel scrapper.

For instance, in case of a video buffer, the content can be streamed from the remote app to the local YUV buffer as a lossy video stream without impacting the quality of the other, non-video buffers of the application. (In fact, I think I remember something to that extent being demonstrated somewhere, although I can't find the link, so don't quote me on this.)

Meanwhile, because Xorg's current rendering extensions are not network-transparent, remoting X applications that use those extensions (which will be most of them, these days) does already boil down to filling generic pixel buffers and pushing them down the wire, which works with the approximate efficiency of... a pixel scrapper.

A Wayland stack should therefore be no worse than a current Xorg stack in most cases, and can theoretically be made to work vastly better. (I don't, however, think we are there yet. See below.)

If you're using only pure-X11 apps, though, stick with Xorg for the time being. At least until the Wayland stack supports X buffers sufficiently seamlessly.

> This leads old X11 users to believe they are either liars or incompetent (and hence the lack of trust) because having experienced them all over many years, I know for a fact it is a long way from the worst.

Only if you are willing to make the mental jump of generalizing the one data point of your own limited experience to the entire world and all the use cases that the Xorg developers have to contend with.

If you're gonna give that much weight to single data points, well, I'm afraid that my own long experience of X11, which has most recently involved telecommuting over a VPN and having to use tools like x11vnc and xpra because Xorg remoting on its own works too poorly, neutralizes your own single data point, and we're back to square one. :)

Unless, of course, you are the sort of person who thinks that their own personal experience constitutes the One Overriding Truth, in which case I don't think there is anything whatsoever to be gained for either of us in this discussion.

> The remote windowing is built into the compositor/windowmanager? I really, really hope someone is making a more sensible architecture than that out there

You appear to think yourself an authority on sensible architectures, so I would suggest you prove it with some actual design and implementation. Otherwise, I hope you will forgive me if I don't trust you nearly as much as I do the guys who are doing the actual work based on actual experience with actual issues. :)

That said:

> otherwise we're going to wind up with a lot of deficient compositors or a lot of duplicated code.


While it could be argued that the many composers/WMs on X already constitutes a lot of duplicated code, I DO agree that the Wayland stack is probably going to be somewhat fragmented for a while, at least until the dust settles.

In practice, I suspect Wayland stacks will end up converging over a shared common ground: probably one display server/composer will emerge as the de facto standard, like Xorg has become the de facto standard of X11 display servers; or Weston itself will evolve into a set of libraries that display servers/composers will be built upon.

But this is only a possible future, and until then, I do think that fragmentation and mismatched composer capabilities is the one big issue with the Wayland budding ecosystem.

Time will tell how big an issue it turns out to be in practice, though.


> The nice thing about X, you see is that it all just works like magic.

I think the entire point is, it's a lot of work for the Xorg developers to make it appear to work 'like magic'. And they'd rather achieve the same result in much saner ways. I don't think I am qualified to claim I know better than them in this, and frankly, you have not convinced me that you are either.

Comment Re:Could somebody explain wayland, please? (Score 1) 77

Hi! I would have liked to thank you for taking the time to reply, but I find it difficult to do sincerely, because your comment adds nothing to the discussion, and even detracts from it.

You appear to be trying to imply, with some aggressiveness, that Wayland precludes remoting.

You could have expressed this concern as an interrogation, and I would gladly have tried to share what I understand about the topic.

Instead, no, a bold, unsubstantiated, sarcastic claim with no room for discussion. This is exactly what I meant about the peanut gallery.

Likewise, the fact you refer to the issues the Xorg developers themselves -- you are aware that they are who you refer to as 'the Wayland folks', right? -- have claimed to have with X as 'FUD' makes you look like someone who dismisses contrary opinions instead of addressing them. That really doesn't help the discussion either.

Unless you do, in fact, know better than the Xorg developers themselves. In which case I'm sure you'll step forward to take over the maintenance of Xorg. Won't you?

As to your implied claim, I addressed it in my reply to Uecker below.

Slashdot Top Deals

Systems programmers are the high priests of a low cult. -- R.S. Barton