"Traditional Linux userspace software" is an informal definition, but let's say something like X. Or your average window manager. Or, say, almost anything from GNOME.
"Traditional Linux users" is another informal definition, but if you use a distro, you're probably a traditional Linux user. Contrast this with an Android user. They run the Linux kernel but the software they interface with is an entirely different breed. The statement "Android is Linux" is true, definitely, but it's inside baseball to anyone but us nerds. The Linux-y aspects are more or less invisible (by design).
I'm not trying to slight either desktop Linux or Android or SteamOS or whatever, just to be clear. I think it's a huge win for Linux, at least in some sense.
I think it's misleading to read "Linux" and imagine "desktop GNU/Linux with all the trimmings." I can't imagine there won't be some way to get that on a SteamOS machine. My skepticism is directed at the idea that Valve will ship anything which, out of the box, resembles a traditional desktop Linux experience. I expect it will be more like an Android experience than Ubuntu, with rather limited access to OS internals, filesystem, package management, etc.
> but let's say something like X. Or your average window manager. Or, say, almost anything from GNOME.
This doesn't apply to embedded Linux, or Linux for servers, which could be argued to be just as "traditional" a use case as Linux for desktops.
Additionally, for the desktop use case, nearly every distribution uses a different window manager anyway. There are such a wide variety of window managers, I wouldn't know how to compute an "average" between them in a meaningful way. Although I use Linux for a desktop everyday, I don't have GNOME installed, and I would barely notice if X was missing and replaced by Wayland or a different component.
> I think it's misleading to read "Linux" and imagine "desktop GNU/Linux with all the trimmings."
Right. It's not Linux for the desktop, or Linux for the phone, or Linux for embedded devices, or Linux for servers, it's Linux for the living room. My point is that due to the diversity of the Linux ecosystem, there really wasn't such a thing as a "traditional" or "average" Linux Desktop in the first place, and that we can't even say Linux for desktop is the "traditional" or "average" use of Linux. Anything running the Linux kernel should be able to call itself Linux, without qualification.
I think it's pretty unlikely that Xorg won't be a part of it somehow. X+extensions is basically the only meaningful, portable, direct interface to video hardware that exists on linux. At least if you want the hardware vendor's own drivers (which steambox obviously would, Nouveau is not up to the challenge).
It would also mean that all the 300+ games that currently work on Steam For Linux would have to be retooled for whatever proprietary windowing layer Valve would have to invent. And Valve would have to convince nVidia to come along for the ride.
The closeness of the SteamOS experience to that of a typical desktop Linux distro is irrelevant. If it runs on the Steam Box, it will run on a Linux desktop of compatible architecture.
Considering there is already Steam for Linux, its probable that Valve will ensure Linux games run on both platforms equally well.
In any case, if there is no need for "all the trimmings", if Valve just wants to make an entertainment pipeline, then that's fine by me. It's the same kernel; this is a huge win for Linux by any measure.
- GPU driver improvements (they've already been working with nvidia, amd, and intel) which everyone benefits from
- kernel patches (maybe they fiddle with the scheduler or something) which anyone could pick up
- new/improved subsystems (perhaps they do some low latency input or audio layer), which (assuming they open source it) distros could choose to adopt or not
- improving porting techniques for bringing games or game middleware to Linux based platforms (everyone benefits)
It's possible that some stuff could be foreign enough to the way it has always been done on linux that it may take some time to make it upstream (see wakelocks from Android finally turning up in the kernel under a different name and a different implementation but providing the same functionality), but if it actually improves things, eventually I suspect the mainline kernel or distros or whomever will come around.
I think you misunderstood the point of my comment.
The context was whether or not "Linux users" will pay money for software. In this respect, the closeness is only relevant insofar as it is useful to discuss "Debian users" in the same breath as "SteamOS users."
Android is Linux, but very clearly not "traditional Linux".
"Traditional Linux" suggests to me the traditional distributions like Fedora, Ubuntu, SUSE, Debian, etc.
It'll be interesting to see how much SteamOS will look like a traditional Linux. Considering the many Linux offerings on Steam, I suspect they'd like to have executable compatibility on that level, which Android probably doesn't have. But will it be as wide open as a traditional Linux? I suspect not.
> Unless you have lots and lots of time to spend micro-optimizing everything, you'll get better performance writing in Haskell.
This is stating the case too strongly. Performance wise, the naive, unoptimized solution in Haskell (ex. using the default String type instead of Data.ByteString, number crunching using lots of iteration\recursion) is going to be much slower than than the naive, unoptimized solution in C or Lua. However, for a given subset of the range between "zero" and "micro" levels of optimization, for a given problem, Haskell may still represent the local maximum.
To me the most important factor for developing on a laptop mentioned in the article is the use of a tiling window manager.
For me an incredibly common task in web development is to have a web browser and 1 or more terminal windows tiled horizontally, side by side, in an [ A | B ] or [ A | [ B | C ]] configuration, where A is a web browser, and B and C are terminals.
In order for this to work for me on a screen resolution <= 1920x1080, the ratio ( width of A ) / ( width of screen ) should be dynamically adjustable using a single key combo, without causing window overlapping. If this ratio is fixed, and cannot be dynamically adjusted by the window manager, I experience one or more of the following problems at any given moment:
1. the web browser window is too narrow, causing wide documents to be clipped and a horizontal scroll bar to appear.
2. A terminal window is wider than 80 characters, causing unnecessary screen area to be consumed which could be better allocated toward the web browser.
3. A terminal window is less than 80 characters in width, preventing the entire line of code from being displayed.
To me Linux is the ideal laptop OS because it's the easiest OS to install a tiling window manager on, and a tiling window manager is what maximizes the platform's primary constraint: small screen area.
Tiling window managers don't maximize the use of small screen area; they ensure you'll almost always be using a fraction of the screen instead of the full screen.
Overlapping windows are the thing that maximized the use of a small screen, because they let you dedicate as much or as little of the screen to any given application when its window is on top.
What you are after, rather, is an efficient way of having the entirety of the windows of multiple apps on screen simultaneously. That's a slightly different problem. I personally get by with a combination of cascaded windows and maximized windows with quick keyboard window switching.
 When you cascade windows such that the bottom left corner of each window forms a diagonal line across the bottom left edge of the screen, you can quickly select whatever window you want with a mouse, usually more efficiently than with a task bar, since the application identity is far more obvious when you can see a rectangle of its contents. And with choice of where each window is in the cascade order, you can get usable data out of multiple windows simultaneously.
I have found cascading to be an unhappy medium in the past. In awesome-wm, I'll tap [Win+Space] to toggle between 100% overlapped (fullscreen with unoccluded task bar) and 0% overlapped (multi-column horizontal). [Win+J] and [Win+K] cycle windows. [Win+H] and [Win+L] resize the width of the primary column in a multicolumn layout.
So let's say I have a terminal window with VIM, and a web browser with a tutorial or documentation open up to the left of it. I quickly need to scroll the web page down to continue the example, BUT the VIM window is currently focused. Assuming the web browser can be scrolled using [J] and [K], I'll simply tap [Win-K, J, Win-J] to accomplish this task while avoiding modifying the layout or leaving the home row to use a pointing device. If I don't actually need to display multiple columns at the same time, I just press the change layout key to stop using a multicolumn layout.
So as a VIM user I've been very happy with this setup in awesome-wm for the past 2+ years, but if you wish to recommend an alternative I will definitely give it an install.
edit: I was able to write a new layout function for awesome-wm which implements diagonal cascading in the manner you described and retains my keybindings. I definitely agree that cascading makes it bluntly obvious which window is the currently focused one. I'll have to play around with it more.
In a multi column layout, I might wish to alter the width of the web browser in the primary column somewhere between 30% to 68%, in 2% increments, by simply tapping [Win+L] to increase its width, or [Win+H] to decrease its width, without worrying about whether it is the focused window, and without worrying about having to focus or adjust any other window after the keystroke was made to prevent overlapping.
If you want a layout where a web browser takes up 60% of the width, and two terminals take up 20% of the width, it becomes not only possible but relatively easy.
> "Global illicit networks — from drug smuggling and arms dealing to human trafficking and organ harvesting — affect millions of people across the world, generating over $2.1 trillion every year. Existing, publicly available information about illicit networks is often not presented in a format that allows the patterns of trade to be easily understood. Applying the power of data visualization to this information can enable a greater understanding of the underlying mechanics of these networks, which in turn can lead to much more targeted and effective efforts to counter them."
This paragraph makes it sounds like they are interested in illicit activity in a general and abstract sense and are considering participating in the War on Drugs.
I skimmed over the Google+ page for "Google Ideas" and it was interesting to see how many of the projects they are working on relate to current world events, actions in the Middle East, "terrorism", and such... all under the premise of analyzing "big data".
I wonder who else, besides Google, has "big data" that they'd like to analyze...
Callbacks have been around forever in C using named functions, and are not specific to either the current generation of programming languages or programmers. One can still use a named function instead of a locally constructed lambda to represent a callback in a high level languages.
The primary difference is that when declaring named functions non-locally, one must explicitly share state through the parameter rather than implicitly sharing state through lexical scoping. It seems more accurate to label the problem of nesting lambdas to the point of ambiguity as "Lambda Abuse" or "Lexical Scoping Abuse" rather than "Callback Hell".
Not totally, the problem being described as "Callback Hell" is in my experience: non-locality of code. Things that relate to one another should be spatially together for a programmer to write, read, understand- and NOT split into success and error conditions around the axis of final callback.
Even with named functions, this is the problem- right? You pass in a named callback and you have to find that function later when you're debugging to figure out what's going on. Locality of code means no breaking context to find something not already on screen and therefore easier programming.
The vote was over whether to add the following ammendment to the DoD appropriations bill:
> None of the funds made available by this Act may be used to execute a Foreign Intelligence Surveillance Court order pursuant to section 501 of the Foreign Intelligence Surveillance Act of 1978 (50 U.S.C. 1861) that does not include the following sentence: ‘‘This Order limits the collection of any tangible things (including telephone numbers dialed, telephone numbers of incoming calls, and the duration of calls) that may be authorized to be collected pursuant to this Order to those tangible things that pertain to a person who is the subject of an investigation described in section 501 of the Foreign Intelligence Surveillance Act of 1978 (50 U.S.C. 1861).
Start by deciding whether you want to target a single platform or a list of multiple platforms, and then choose whether you want to work with 2D, fixed pipeline 3D, or programmable pipeline 3D.
For single platform 2D, research the platforms standard development kit. For cross-platform 2D, find a library exposing an API supporting all available platforms. For cross platform 3D, create a list of hardware you wish to support and find the maximum common OpenGL\GLES version and GLSL shader version.
This should give you an idea of the graphics API you will be working with and need to learn.
 http://www.libsdl.org/ is one such library if you go this route, I believe it's used in Angry Birds and Valve's Linux port of Steam.
Whatever one's thoughts on the article in its entirety, the initial implication that the thinkers listed could not account for Herzen's fish is disingenuous.
Helvetius (one of the listed):
"The free man is the man who is not in irons, nor imprisoned in a gaol, nor terrorized like a slave by the fear of punishment ... it is not lack of freedom, not to fly like an eagle or swim like a whale."
If freedom refers not to the biological limitations and fundamental nature of man, as the author repeatedly asserts during the construction of their straw opponent, but refers to whether man is in chains, then it becomes possible to generate empirical measures demonstrating "progress" in terms of freedom:
At the beginning of the 19th century, serfs and slaves made up 3/4s of the world's population.
And now beside having more slaves than any other time.in history in absolute numbers without counting prisoners in countries that allow prisoner slavery, like the US, we have people.that would happily.volunteer to.be slave if.they had a guarantee of food, we have sweatshops, we have young people desperately working in jobs they hate to pay student debts
Oh, I am not slave, I am free, I am free to work in whatever job I find, or die starved and in debt.
There are an estimated 12-27 million people currently in slavery. With a current world population of 7 billion, this proportion is between .0017 and .0038, a dramatic decline, and probably the lowest in history.
Regarding incarceration in the United States, despite a 10X increase in population from 31.4M to 311.8M and mandatory sentencing policies associated with the War on Drugs, the absolute number of Americans incarcerated in 2011 (2.2 million) was still less than the absolute number of Americans in slavery alone in 1860 (3.9 million).
If you wish to move on to economic issues and contend there has been no progress in living conditions, a point the author of this article does not argue, I would challenge you to produce some actual metric and numbers for a similar period of time (after the dawn of philosophical liberalism) showing the average worker to be no better off, keeping in mind the enormous increase in life expectancy and GDP per capita which has occurred.