I thought 2014 was a typo, but the video is actually 1.5 years old. Does anyone know the current status of the project? There is no recent Twitter activity from the project, but I don't know whether that means no-one is working on it or there are people working on it who rather spend their time on engineering than writing tweets.

Additionally, Microsoft has taken matters in to its own hands, removing access to their consoles entirely. Microsoft permanently disabled their Xbox LIVE accounts (as well as other suspected accounts present on their Xbox One kits) and temporarily blocked all of their Xbox One privileges - meaning that for a period of time which Microsoft decides on depending on the severity of the offense, their Xbox One is entirely unusable.

If this was a retail unit then it is an overreach. But if "kit" refers to a dev/debug kit, then I can see how an NDA violation would get their access cut.

[submitter's note]: some details in the announcements seemed a bit weird to me, notable, I quote, "The core requires Python 3.4 while Postorius and HyperKitty require Python 2.7.". Why use two different (and maybe incompatible) versions of python ?

That's not a 'maybe': Python 2.x and 3.x are incompatible, since Python 3 made some backwards incompatible changes to clean up the language. While it is easy enough to run each process in a different Python version, it would simplify things if they just updated all subprojects to Python 3.x. There is a conversion tool for it (2to3) that works pretty well in my experience.

I think "inexplicably" is not the right word here: Google Code is not making money (search), is not a strategic investment (Android) and is not breaking new ground (self-driving cars). The only reason to keep it around would be loyalty to its users, but that doesn't seem to be high on their list of priorities.

Relying on the continued availability of a third party service is a risk, no matter whether the service provider is a startup (see Our Incredible Journey) or a large established company like Google. At least in the case of project hosting, it is relatively easy to migrate to a different service, which is not always the case when other services or APIs get shut down.

The wine bottle with a plastic bladder sounds much like existing cardboard containers, except that it's a cillinder instead of a block. Maybe the shape helps break into the mid-price segment (the author who claims $15 wine is for "chugging" must live in a different world), but it's not a big step in my eyes.

The beer bottle on the other hand, without the plastic bladder, is actually a step forward in terms of recycling: while cardboard and plastic can be recycled when separated, that is not possible or worthwhile when they are joined together, as far as I know.

My first urge was to start ranting how Word is anything but genius, but I calmed myself down and read the article first (that's allowed here, right? ;). I think I understand what the author is saying, although I don't entirely agree with it.

WP had (I haven't used it in decades, so I don't know if it's still true) a much simpel model for storing the document than Word. It was just a bunch of "bold on", "bold off" etc codes, similar to HTML tags. There was a mode in which you could display and edit those markup codes directly. That made it relatively easy to visualize what WP was doing internally.

WP was also terrible in my opinion. It would often get the codes into such a mess that the high-level editing couldn't produce the right result anymore and you were forced to hand-correct the markup tags. Some people liked having that kind of low-level control, but to me it felt like being forced to clean up after the program made a mess.

When I first used Word (Word for Windows 2.0), I really liked it. No more messing around with markup codes. And wysiwyg was great for trying different layouts without having to make a dozen prints. But that changed as both Word and the documents I was editing became more complex. Instead of short letters and greeting cards, I started to write reports with embedded illustrations and formulas, tables of contents and often co-writing them with other students.

In particular having multiple people working on a document caused problems. Track Changes didn't play well with auto-numbering and ToC, marking text inserted automatically by Word as changes. Different authors had different ideas about layout: some used direct formatting and some used styles, but even the ones using styles picked them based on the way they looked and not for their semantic role in the document. And they would use various tricks to get the right visual effect, which would fail when other parts of the document changed, or even when switching to a different printer. (If you want a page break before a new chapter, configure that in the header numbering style instead of attempting to fake it by inserting empty lines until the page wraps, grrr...)

Coming back to the article, WP has a simpler model that the writer can directly see and manipulate. This allows the writer to bend WP to their will with some moderate effort: it is not WP being mediocre but right, it is WP being mediocre and the user making it right. Word has a more complex and less visible model, which is great when it works well, but very hard to diagnose when it fails. And it will fail, both because users are not using it properly and because Word itself has bugs and misfeatures that will mess up the document. Comparing Word to Plato suggests that it isn't possible to do real-world word processing based on an ideal model. It might be true that any tool has to compromise to real-world concerns at some point, but I'm convinced that it is possible to do so with far less kludges than Word.

Word tries to support two approaches at once: direct formatting where you change the properties of the text until it looks good and structured documents where the look of a text fragment is determined by its style. I think a lot of problems could be avoided if each document would use either direct formatting or styles exclusively.

I also think Word encourages bad habits by offering formatting features at every step of the way. It distracts from the writing of the text itself, it often leads to inconsistent layout decisions and it wastes time because effort is put into formatting text that will later be deleted or merged. So the last decade and a half I've been using DocBook, HTML and MarkDown, where I can write focusing on just the text itself and worry about the layout later.

It's written as "Qt". Otherwise people might confuse it with QuickTime.

PCs are expensive, prone to failure, easy to break and magnets for viruses and malware.

The claim that super tablets would improve on those aspects doesn't sound very realistic to me. If tablet hardware is equally powerful as PC hardware, but has to be lightweight and run on a battery, it will be more expensive. A stationary PC is also less likely to break than a portable tablet of equal build quality.

How prone a machine is to viruses and malware depends on a lot of factors, such as OS, obscurity of the platform, level of clue from both the admins and the users etc. None of those factors are related to the hardware: if a tablet OS is easier to secure and still flexible enough for the users to get their job done, why not install a tablet OS on PC hardware?

The only advantage of a super tablet over a laptop is the form factor: it is easier to carry around. That can be important in some companies. But it will cost extra, not less.

I think the value of a news site that doesn't have original content is in finding articles that I wouldn't otherwise have seen. So I would recommend to not monitor the popular sites, but look for articles on less known sites, blogs etc.

Ah, clicking the "N votes" link allows you to vote. That's not very obvious.

How do I vote? There is nothing clickable in my browser, which is Konqueror rendering using WebKit.

I'm not a big fan of systemd, but I disagree with the idea that sysvinit didn't need replacement.

It required a large amount of boilerplate in the service start/stop script, which was different between distros, making it a lot of work to provide a decent start/stop script for your daemon. The hard work of distro maintainers hid this nuisance from most end users though.

Ordering the service startup sequence by manually assigning priorities to them (S80myservice) instead of using dependencies is a terrible hack. It also prevents services from being started in parallel, which is a pity on today's multi-core systems. It's like building your code using a shell script instead of a Makefile.

There is no consistency in how services are started: inittab can respawn, init.d scripts can query the service status (on some distros!), (x)inetd can start services on demand, but all have different configurations.

I have some doubts systemd is the right solution to these problems, but at least there is movement now. In my opinion, the solution would be to improve systemd or replace it with something better, not going back to sysvinit.

Enter a few passwords that you used in the past but are no longer in use and not similar to passwords that are, plus a few random passwords you never used. Check what they report back.

XBox Entertainment Studios had a short life. It was announced only a year ago, but design decisions led to poor reviews. Among its weaknesses, the software was bloated and slow, and Microsoft not only hobbled it with DDR3 memory but also needlessly restricted the games to using only 6 of the 8 cores.

You're mixing up the XBone and the studios here...

To me it looked like GNOME2 had better polish in both themes and apps, while KDE3 had better underlying tech (Qt, KIO, DCOP, KParts etc). It would probably be less of an effort for GTK theme writers to build a good looking Qt theme than to keep a themable GTK library alive, since the GNOME3 developers seem hostile to the very idea of theming the desktop.

I don't think the GNOME3 developers are necessarily wrong: you can't have a highly customizable desktop that also provides a consistent and instantly recognizable look and feel. KDE chose customization and accepted that not every combination of settings works equally well and that every distro's and person's KDE desktop looks and feels slightly different. GNOME3 seems to choose the other option, but doesn't go all the way and keeps a bit of customization limping along. In my opinion it would be better for everyone involved if they would just cut out the theming functionality altogether: the GNOME devs get to build their single consistent user experience while the theme authors would be spared the frustration of their themes being broken in every new GTK release.

Around the year 2000, a big reason GTK became popular was licensing issues with Qt. But Qt has been licensed under LGPL (same license as GTK) for 5 years now and under GPL for a lot longer.

More language bindings has been mentioned as a reason, but are there languages one would want to write a GUI in which lack Qt usable bindings and do have usable GTK bindings? I once tried programming GTK in plain C, but trying to use objects using library functions and macros instead of using an OO language just felt awkward and led to hard to understand compile errors. I must say that I found PyQt a bit awkward as well, since it never really felt like you were programming Python: it was always clear it was Python code talking to a framework written in a different language. So it made me question the usefulness of GUI toolkit bindings in general.

Qt has better cross-platform support than GTK. The last time I used a GTK app (Inkscape) on Mac OS X, I had to run an X server and it looked really out of place; a quick web search suggests the X dependency is gone but integration with the native desktop is still minimal. GTK on X-less (framebuffer or EGL) embedded Linux is unmaintained as far as I know. I don't know the state of GTK on Windows because I haven't seriously used Windows in a long time.

Qt has a strategy for supporting touch devices (Qt Quick), seems to be on track supporting Wayland and is adapting its drawing model to better fit modern graphics hardware (scene graph instead of immediate drawing). GTK could be forked to keep compatibility with themes and non-GNOME applications, but it would require a lot of effort to keep up with current trends (not all of which are hypes that will blow over).

Another thing Qt has going for it is that the KDE libraries are being modularized, so instead of one big set of kdelibs there will be a lot of smaller libraries, some of which depend only on Qt and some which are connected to a whole lot of other KDE libraries (there are 3 tiers for different allowed dependencies). This means that some of the functionality developed in the KDE project becomes available to Qt applications without those applications having to tie themselves to the KDE desktop.

Because I get the distinct impression the NSA has broken Internet encryption protocols and is busy getting all up in your stuff.

The fact that they pressured Lavabit to give them the private keys suggests that they couldn't just break the crypto using only their math skills.

That's indeed one of the things that annoys players: a game advertising itself as free to play, but not actually being playable in a practical sense unless you pay. In the shareware games it was completely impossible to progress beyond the first episode unless you paid, but you were told that before you started to play.

The Apogee/ID shareware model from the 90's was also a kind of freemium: episode 1 is free, episode 2 and 3 are sold. The problem is not in having a free/paid combination, the problem is greed. Game development costs money, so there should be money coming in or the development can't continue. But in some companies bringing in money becomes more important than making a game and the game play suffers as a result.

I agree with the patching problem: the nice thing about consoles used to be that you could just pop in a cartridge or disc and start playing, without having to worry about system specs, drivers, hard disk space etc. Nowadays game discs are just a workaround for people having slow net connections, because you can't play from the disc anymore: you have to install the game and then patch it.

The patching is mostly a problem with the AAA titles though: indie titles tend to be much smaller in size and scope, if only because of smaller budgets. They also tend to be released when the developer considers the game ready, instead of at a time set by upper management. Since I get most of my games from Humble Bundle and Kickstarter nowadays, I mostly know the patching problem from friends who do own recent consoles.

About online harassment: yes, that's a problem, but in 1994 there was hardly any online gaming except for MUDs. I'm not convinced that gamers from 1994 would have been kinder to each other if the masses had been online then.

It's the ultimate 8-bit machine: 7 MHz (*1) Z80-compatible CPU, 512K main RAM, 128K video RAM, FM synthesis (OPLL), MIDI, adjustable speed autofire on space bar. Full specs here .

(*1) The original Z80 took 4 ticks for even the most basic instructions, more unless paired with fast RAM. The R800 in the turbo R can do them in 1 tick. So it's a lot faster than what the clock speed would suggest. For an 8-bit machine, that is.

While I still have it wired up, I must admit that I only really start it when doing research for the openMSX emulator. If I want to play old games, I do it in the emulator: it is just more convenient with save states, reverse, cheats etc.

X is from a time when flexibility was considered more important than security. So I'm not surprised it is weak in this respect.

If you create a second login session at the display manager, I think that would be shielded from the first: they would be talking to the same X server, but to different displays. If I understand X correctly, snooping is possible between applications connected to the same display (X display, not a physical monitor).

Hmmm... I'm able to moderate my own posts.

It is not just a bad idea to return a password through an API; a properly designed application wouldn't even be able to offer such an API call because it would store password hashes instead of actual passwords.

If it's a cost-cutting operation, it might be related to the poor Wii U sales. If they're doing it in the hope Wii owners will buy a Wii U, I doubt that will work. I have a Wii and I never played online with it, so some users won't even notice the difference. People who will miss online play have to buy a new system and new games, so there is nothing that binds them to Nintendo. And since Nintendo was the one who switched off the online component for a system that was sold less than half a year ago, I don't expect they'll get much loyalty from those users.

The channel topic on the ##atom IRC channel (freenode) is "Mac beta; Linux/Windows in the future; http://atom.io".