User: Password:
|
|
Subscribe / Log in / New account

Day: GNOME OS

On his blog, Allan Day has posted an overview of GNOME OS with a description of what it is (and isn't) based on discussions at the recently concluded GUADEC. "Many of the things that we want to do as a part of GNOME OS are old ideas that have been around in the GNOME project for a really long time. The aspirations that are driving this process include things like providing a better experience for application developers, automated testing, sandboxed applications and broad hardware compatibility. While each of these goals could be pursued independently, there are enough interconnections between them to make a holistic plan worthwhile. Yes we could call the initiative something else, but GNOME OS has stuck, and it kinda fits (as I hope to explain a bit better below)."
(Log in to post comments)

Day: GNOME OS

Posted Aug 8, 2012 2:43 UTC (Wed) by slashdot (guest, #22014) [Link]

Translation: most distributions no longer ship our software nor believe in us, so we are going to make our own distribution.

Problem: they would also need to ship their own hardware for it to work (esp. on "touch devices"), which requires convincing someone to invest in a platform with "GNOME OS" rather than, say, Android or Ubuntu with Unity or an Android + "Ubuntu for Android" combo.

Good luck with that.

Day: GNOME OS

Posted Aug 8, 2012 5:51 UTC (Wed) by drag (subscriber, #31333) [Link]

translation: Did not actually read blog post.

Day: GNOME OS

Posted Aug 9, 2012 17:55 UTC (Thu) by jospoortvliet (subscriber, #33164) [Link]

His name is 'slashdot', what did you expect?

Not that I think the GNOME OS is such a stellar idea but it's not too stupid either. It'll probably be Fedora based, hope that won't piss off any more people :D

Day: GNOME OS

Posted Aug 10, 2012 14:06 UTC (Fri) by walters (subscriber, #7396) [Link]

I hope and expect that some of the technologies driven by GNOME make their way into Fedora. Improving the quality of what we make in GNOME is the entire point of the effort.

And just speaking for myself, I will avoid doing anything in GNOME that would harm our ability to be used in larger software collections. For example, I designed the build system to *not* have any duplicate metadata, and I want things like the devel/runtime split to be standardized upstream, so they can be consumed by all of RPM spec files, debian/rules, bitbake recipes, etc.

Day: GNOME OS

Posted Aug 10, 2012 14:12 UTC (Fri) by walters (subscriber, #7396) [Link]

Day: GNOME OS

Posted Aug 10, 2012 1:17 UTC (Fri) by dskoll (subscriber, #1630) [Link]

slashdot surely overstates the case. Nevertheless, I think it's interesting that Debian is going to make the default desktop XFCE in the next release. They claim it's to save space on a minimal desktop CD image, but that's still got to be of some concern to the GNOME crowd.

Day: GNOME OS

Posted Aug 10, 2012 14:33 UTC (Fri) by ebassi (subscriber, #54855) [Link]

we actually had Jordi Mallach as a representative for Debian at the Advisory Board meeting at GUADEC, and we had good discussions and collaboration on how to improve the Debian packaging of GNOME. plus, the GNOME OS/Testable effort will make it easier for Debian (and other distributions) to do QA on GNOME, and to package it more quickly.

the XFCE thing has been considerably overblown in places like Slashdot and Phoronix.

Day: GNOME OS

Posted Aug 10, 2012 15:20 UTC (Fri) by dskoll (subscriber, #1630) [Link]

the XFCE thing has been considerably overblown...

OK, if you say so. I guess confidence is good.

Day: GNOME OS

Posted Aug 10, 2012 16:27 UTC (Fri) by ebassi (subscriber, #54855) [Link]

the change is in unstable, and it's not been automatically propagated to Wheezy.

after the change Joss made, a lot of the GNOME packages have been resumbitted with a different compression, which makes it easier to switch back to GNOME as the default UI.

but even if that weren't the case: the important thing to take away is that the GNOME project is engaged in productive discussions with all downstream packagers, and it's actively trying to improve the QA and development for both distributons and software developers - something that has been a sore point of the project for many years.

obviously, we get kicks in the head both if we don't do things, or if we do, so it's par for the course, I guess.

Day: GNOME OS

Posted Aug 8, 2012 2:57 UTC (Wed) by cmccabe (guest, #60281) [Link]

I kind of hate to say this, because I know there are good engineers and good intentions behind GNOME, but I can't see this ending well. It kind of ties into what Benjamin Otte was commenting on last week: what are the goals for GNOME? Is it building a Linux distribution? Creating an OS for tablets and smartphones? Is it going to provide a low-level framework comparable to SELinux or seccomp? Is it going to create a new build system to compete with Koji, CDBS, or the Gentoo build system? Or maybe (and I know this is a stretch) it should produce a usable window manager? Nobody seems to know. And I'm willing to bet that most of the wheels that get re-invented here already exist in rounder form elsewhere.

In particular, the "GNOME SDK" stuff makes me sad because I still use some GNOME software. If I have to install a huge monolithic clot of uneccesary dependencies to use gnome-terminal, for example, I will simply have to find another terminal program. GNOME was always relatively modular, unlike KDE. But this is almost like a declaration of secession from the wider open source community. Thumbs down.

Day: GNOME OS

Posted Aug 8, 2012 3:22 UTC (Wed) by slashdot (guest, #22014) [Link]

I believe it's pretty clear what they want: they are envious of the popularity of Android and iPhone and want to clone/replace them.

But as I said above, they need to ship hardware and need to invest a ton of money to compete in that space.

And what they don't realize is that, relatively, they just don't have any money to do that:
- Apple has a 582B market cap with 14.60 P/E
- Google has a 209B market cap with 18.89 P/E (+ partners like Samsung with 172B market cap, etc.)
- RedHat has a 11B market cap 74.48 P/E

And Red Hat, even if they decide to invest in GNOME OS, has no experience whatsoever in the consumer space, and actually actively threw all their consumer users under the bus with the Fedora rebranding.

Non-Red Hat investors, on the other hand, seem much more likely to go with Android or with Ubuntu, which has a consumer-focused company backing it, has a sizable user base, a better UI and Android integration already done.

Meanwhile, they seem to put no care whatsoever in keeping their existing open source community users while pursuing their pie-in-the-sky goals, and hence can't even rely much on free contributions to save money.

Plus, of course, even with money they would actually have to ship good software, and I'm not quite sure the GNOME developer actions show they have the skill to write it.

Day: GNOME OS

Posted Aug 8, 2012 6:05 UTC (Wed) by drag (subscriber, #31333) [Link]

> But as I said above, they need to ship hardware and need to invest a ton of money to compete in that space.

Linux netbooks based on existing distributions shipped and were the #1 most popular devices for a number of months.

It took about six months or so for the general computing public to figure out that what was being shipped was absolute junk and that it was more then worth it to spend a bit more money on something that could actually run Windows XP effectively.

They also realized very quickly that trying to replace the Junk Linux distributions shipped on their hardware with Ubuntu or other hyped systems resulted in just more junk and unusable installs.

Meanwhile you had folks trying to turn a Linux distribution into a mobile system for phones and tablets and failing miserably. As soon as they got something that was half-way usable they would abandon it and start over with a new toolkit or new custom Linux distribution.

The 'Linux Desktop' had it's chance and it failed miserably. People couldn't install software, developers failed to focus, and roving bands of lusers roamed various forums lambasting every attempt to improve things and just went out and bought Windows hardware to try to install Linux on because it had more variety... only to find out that Linux support wasn't there.

It's not terrible or unfortunate for people actually still interested in the Linux desktop to try to actually make the Linux desktop usable. It's not bad to examine what went wrong with Linux distributions and what went right with iOS or Android... when they were both corporate backed AND developed simultaneously.

If you want to make money and garner users and developers you have to actually make something worth spending money on, is usable, and easy to develop and install software on first.

> I believe it's pretty clear what they want: they are envious of the popularity of Android and iPhone and want to clone/replace them.

OMG, Gnome wants to make installing and developing software easy and improving the ability to utilize user's hardware... Oh what a bunch of self-centered envious dicks!

Day: GNOME OS

Posted Aug 8, 2012 7:03 UTC (Wed) by kragil (guest, #34373) [Link]

XP had the applications people wanted, that is not Linux fault.
People just want their apps. So the Gnome people (Red Hat) should just stop all that nonsense and just write apps for Qt, instead of starting all over again on every possible level based on nearly abandoned GTK.

At this rate and with the usual time slips "Gnome OS" will be done by 2015 (maybe). Windows, Android, IOS, OSX and even ChromeOS, Tizen, FirefoxOS and OpenWebOS will be far more ready for what the future holds at that point than anything a few dudes at Red Hat dream up.

Day: GNOME OS

Posted Aug 8, 2012 7:48 UTC (Wed) by drag (subscriber, #31333) [Link]

> XP had the applications people wanted, that is not Linux fault.

> People just want their apps. So the Gnome people (Red Hat) should just stop all that nonsense and just write apps for Qt, instead of starting all over again on every possible level based on nearly abandoned GTK.

The logic doesn't follow. If people wanted XP because of the applications then what benefit would Gnome get by abandoning everything and starting over with QT? By getting rid of all your applications then you get lots of applications? Doesn't make sense. It would make more sense if your arguing that Gnome should be re-written using Winelib and Mono so that it gains greater compatibility with existing Windows applications.

Abandoning a existing and functional GTK-based platform for QT is what Nokia tried to do with their Linux distribution and it turned out to be a disaster. Now all the QT developers are rapidly being laid off, the QT copyrights are in the hands of a failing corporation that exists as little more then a Microsoft vassal and the people (KDE, etc) that depended on QT's propriety variants to fund the development of their platform of choice now are on their own.

Toolkit changes doesn't seem like likely to yield much of a benefit.

Day: GNOME OS

Posted Aug 8, 2012 8:29 UTC (Wed) by kragil (guest, #34373) [Link]

Building a house on sand? GTK is dying/certainly stagnating. Qt will have a healthy ecosystem even without Nokia(or RIM or HP). And Qt5 is years ahead of GTK. At this rate maybe in 2020 GTK can do what Qt can do now.

Everything the current Gnome dev touch turns to crap, so maybe I should be careful what I wish for. Only the anouncement of the new nautilus changes produced a fork (nemo) in no time.

And they obviously want to rewrite everything anyways .. so?

Day: GNOME OS

Posted Aug 8, 2012 8:45 UTC (Wed) by drag (subscriber, #31333) [Link]

> Building a house on sand? GTK is dying/certainly stagnating. Qt will have a healthy ecosystem even without Nokia(or RIM or HP).

QT being healthy without QT devs remains to be seen. But I with all the luck to them.

I still think that the toolkit is relatively irrelevant to other aspects of the platform and it always will be.

> . Only the anouncement of the new nautilus changes produced a fork (nemo) in no time.

People have created forks of Gnome stuff since back Gnome 1.x days as a sort of protest. Almost all of them die fairly quickly after the first release, but I don't think it's a terrible thing that people are that passionate about Gnome software.

Maybe if you go off and start a QT version of Gnome then maybe then you can prove to people how awesome QT can be without KDE. Personally I think it would be easier just to stick with KDE and try to make that more Gnome-like if that is truly your goal.

Day: GNOME OS

Posted Aug 8, 2012 8:46 UTC (Wed) by drag (subscriber, #31333) [Link]

er, sorry:
But I with all the luck to them.
means to read:
But I wish all the luck to them.

And I am serious about that.

Day: GNOME OS

Posted Aug 8, 2012 9:06 UTC (Wed) by paulj (subscriber, #341) [Link]

People have created forks of Gnome stuff since back Gnome 1.x days as a sort of protest.

FWIW, as a GNOME user since those days, I can't remember noticing any such forks, until GNOME 3. The first time I noticed GNOME having forks was Mint/Cinnamon and then MATE, both of which appear have built up sufficient momentum to achieve escape velocity, and be more than protest "flash in the pan" projects.

Day: GNOME OS

Posted Aug 8, 2012 9:46 UTC (Wed) by drag (subscriber, #31333) [Link]

GoneME is the one that generated the most fervor that I can remember:
http://www.akcaagac.com/index_goneme.html

The funny thing is that looking back to his complaints a great number of them have been addressed since 2004. Gconf is replaced by dconf, although probably it is something he would consider worse. Mozilla has been replaced by KHTML derived Webkit. Dependencies for Gnome have been much streamlined. Spatial Nautilus is gone. And a few other details.

I know that abandoning things like Sawfish and going with something much simpler really really pissed off a huge number of people for a very long time. I didn't really pay much attention to Linux political things back when I first started using Linux (and was delighted to learn I didn't need Gnome to run Enlightenment.) but I was still seeing Gnome 2 hate coming from people who liked all the configuration options and scripting that was available for Gnome 1.x up until a couple years ago.

Gnome forks as a response to Gnome 3 really amount to Cinnamon and Mate.

Mate should of been completely unnecessary. Looking back it's a stupid mistake of Gnome project to not make Gnome 2 and Gnome 3 install-able in parallel. Once they achieve the ability to easily install Gnome 2 on everybody's system that cares about it they will probably just go into maintenance mode.

Unity/XFCE et al started long before Gnome 3.

Cinnamon is a real swear-to-goodness fork of Gnome Shell to make it more Gnome 2 like. I actually see that going somewhere eventually. I was hoping they could it just through extensions, but I guess that was not possible.


Day: GNOME OS

Posted Aug 8, 2012 16:19 UTC (Wed) by nevets (subscriber, #11875) [Link]

> I know that abandoning things like Sawfish and going with something much simpler really really pissed off a huge number of people for a very long time.

I know I was one of them. Although, I was able to replace metacity with sawfish in the gnome environment, even though it seemed that gnome kept making switching the window-manager harder at each release. I even eventually did:

# rm /usr/bin/metacity
# ln -s /usr/bin/sawfish /usr/bin/metacity

and that worked well :-)

> Looking back it's a stupid mistake of Gnome project to not make Gnome 2 and Gnome 3 install-able in parallel.

And this has been my #1 complaint about Gnome3. I just don't work well with the gnome3 workflow. I really liked gnome2 and after a decade of tweaks I really streamlined my workflow with it. Gnome3 destroyed that. I've said it in the past and I'll say it again...

The biggest thing I hate about Gnome3 is that it took gnome2 away from me.

Day: GNOME OS

Posted Aug 8, 2012 23:42 UTC (Wed) by cortana (subscriber, #24596) [Link]

May I ask what you think about Fallback mode? Once someone pointed out that you have to hold down Alt while clicking on the panels to customize them, I felt right at home.

Day: GNOME OS

Posted Aug 8, 2012 9:36 UTC (Wed) by BlueLightning (subscriber, #38978) [Link]

Abandoning a existing and functional GTK-based platform for QT is what Nokia tried to do with their Linux distribution and it turned out to be a disaster.

Seems to me that had more to do with other things going on at Nokia than whether Qt was an effective toolkit or not. Not that I think GNOME making a leap to Qt would be helpful though - it would just take a very long time, push a bunch of developers away from the project and probably not actually achieve anything anyway. Those calling for it probably don't know what they are asking for.

Day: GNOME OS

Posted Aug 8, 2012 10:18 UTC (Wed) by drag (subscriber, #31333) [Link]

I think the toolkit is largely irrelevant.

I believe this because it appears that things like GTK vs QT is dwarfed by other, far more important, issues related to the Linux platform as a whole. And as such is seems very likely to me that switching toolkits will yield no positive net benefit; yet require a massive amount of work. Work that is better spent addressing other issues and improving existing applications.

Day: GNOME OS

Posted Aug 8, 2012 13:45 UTC (Wed) by boudewijn (subscriber, #14185) [Link]

It seems to me that the gnome, too, decided that GTK isn't the right toolkit to create attractive applications for a mobile environment -- hence Clutter. And, of course, Qt isn't just a toolkit, it's way more that than, and Nokia actually, while using Qt, switched toolkits a couple more times, from QWidget-based DUI (might be mistaken about the official name, we used it for Fremantle office on the N900) to libmeegotouch to Meego QML Components.

Having used it, I have to say that libmeegotouch in particular was a travesty of everything that makes Qt so wonderful to work with. Bad documents, ghastly performance, horrible API.

QML is pretty nice, though.

Day: GNOME OS

Posted Aug 8, 2012 16:12 UTC (Wed) by juliank (subscriber, #45896) [Link]

No, almost nobody wants applications written in C++.

Day: GNOME OS

Posted Aug 8, 2012 16:53 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

So…what browser do you use? uzbl is C, but webkit dwarfs its size and is C++. dillo? w3c? elinks?

Day: GNOME OS

Posted Aug 8, 2012 17:00 UTC (Wed) by juliank (subscriber, #45896) [Link]

Unfortunately, some software is written in C++, so we can't live C++-free. But that's not a reason to write even more software in it. There are several reasons for this:

* Fragile ABI. libstdc++ ABI is partially different when using -std=c++11, so combining C++11 code bases with older code bases is fragile.

* Build time explosion. The extreme use of inline code and templates causes an increase in build times (especially if you use boost stuff or STL).

There are probably other reasons to avoid C++ when reasonably possible, but I don't want to continue writing this comment.

Day: GNOME OS

Posted Aug 8, 2012 17:59 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

libstdc++ ABI is being addressed. It's already backwards-compatible, but not very developer-friendly for the new code.

Build time of QT-based software is not significantly greater than GTK-based software.

Day: GNOME OS

Posted Aug 8, 2012 23:29 UTC (Wed) by Company (guest, #57006) [Link]

I am sorry?

C++ compilers are orders of magnitude slower and more memory-intensive than C compilers.

http://www.phoronix.com/scan.php?page=news_item&px=MT... builds Linux in less than 1 minute on a single core. A Firefox (which is less code size) build according to Firefox's build farm at https://tbpl.mozilla.org/ takes from slightly less than an hour to 2 hours.

Day: GNOME OS

Posted Aug 9, 2012 0:05 UTC (Thu) by hummassa (subscriber, #307) [Link]

You just compared "You can run 5 km in two minutes in a Ferrari, but it takes more than one hour to run 30 km in a bycicle!"

Day: GNOME OS

Posted Aug 9, 2012 2:37 UTC (Thu) by Company (guest, #57006) [Link]

I'm not sure how you got to that comparison, but I'm waiting for you to prove me wrong. Go ahead.

Day: GNOME OS

Posted Aug 9, 2012 2:46 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

First, that's not single *core*, but *socket* for the kernel build. Second, it's a $1050 processor. That's the Ferrari. I couldn't see what the build farm was using, but it's not /that/ good.

Better would be to compare Koji's build times for the packages (though you'll need to factor out the root.log time due to different dependencies). Bonus points for getting builds from the same host at low load.

Day: GNOME OS

Posted Aug 9, 2012 3:04 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

The build farm is also running tests which I can imagine taking a long time. In fact, looking at the logs, they're using ccache which tells me that its 60 to 120 minutes of running tests which is more than the kernel can say.

Basically, your comparison is: "more" C is compiled by a top-of-the-line CPU in one minute than some random build farm hardware can test "less" C++ code. Never mind that the build farm builds also start by doing lots of PyPI installs (mostly cached) whereas the kernel build goes straight to building stuff.

Day: GNOME OS

Posted Aug 9, 2012 21:05 UTC (Thu) by ibukanov (subscriber, #3942) [Link]

Build farm is slow. On a 4-core Linux desktop (Core i5-2400 CPU @ 3.10GHz) Firefox builds in about 15-20 minutes depending on the build configuration. But I second the observation that extensive use of c++ makes things much slower.

SpiderMoneky, the JavaScript engine in Firefox, used to be written in C. The compilation of JS shell (that compiled only the engine without any other Firefox code) to test changes to the engine was fast. It was possible to develop it even on a netbook as the shell compiled under a minute there. Then the code switched to C++ and the build time deteriorated as more and more C++ features started to be used. In a less than a year one could forget to use netbook for any productive development and even using not the latest and greatest notebooks became problematic.

Day: GNOME OS

Posted Aug 9, 2012 23:48 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

I agree that C++ is slower to compile, but as I said elsewhere:

> As for build times, yes, it's higher, but I don't really notice that much of a practical difference and what difference there is is well worth the extra safety the code has.

Unfortunately, a fair comparison can't be made without ensuring at least feature parity between the C and C++. You also have to compare bug counts and code ease-of-use (for users of the code/APIs, developers, and maintainers) and in this, C++ is a big win IMO.

The C++ SpiderMonkey has more features today than it used to have (I expect) and you have to weigh how long it took to code those features versus how long it would have taken with the C codebase to get the same features against the increased build times.

As for using a netbook, I don't know what my limits for patience would be anymore. After using my i7 and Xeon machines at work, even my Core 2 Duo was getting me impatient with builds. I don't do much beyond script-level stuff (usually Haskell, shell, or Python) or minor web development on the netbook anymore mainly due to the tiny screen (my terminals at work are 319 wide and 88 tall and netbooks just don't fit 3 80-wide Vim windows plus NERDTree on them at readable font sizes).

Day: GNOME OS

Posted Aug 10, 2012 10:38 UTC (Fri) by jwakely (subscriber, #60262) [Link]

A large part of slower C++ build times is in the linker, not just the compiler. Using Gold makes a big difference.

Day: GNOME OS

Posted Aug 10, 2012 20:05 UTC (Fri) by ibukanov (subscriber, #3942) [Link]

Surely C++ brought a lot of nice things like templates and destructors for automated cleanup significantly simplifying the code in SpiderMonkey. However, a significant compilation time increase also meant that hardware that developers use is way beyond capabilities of the most computers where Firefox runs. So it is much harder to extrapolate the effect of changes that looks nice on fastest CPU during development to the hardware that users will face.

Day: GNOME OS

Posted Aug 8, 2012 18:30 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

As someone who likes coding guarantees with the language rather than logic (Haskell is nice in this regard, but I'm still mainly doing C++), C can't help in many places. Sure, there are ways to enforce things socially with code reviews and such, but it's time consuming to check stuff when I can have the compiler do most of that work for me. C-style casting is also no substitute for static_cast and dynamic_cast.

I do agree that C++ has warts (mainly where they tried to be compatible with C…and didn't quite make it[1]). Not specifying an ABI was silly (an FFI would have been much better). Common stuff is finally in the standard (much is also just boost:: -> std:: moves, so migration once we support C++11 more widely is largely just a rename in a bunch of typedefs in the codebase).

As for build times, yes, it's higher, but I don't really notice that much of a practical difference and what difference there is is well worth the extra safety the code has. It also helps to put most of the heavy Boost template magic in its own source file helps to minimize rebuilding of that file (e.g., the Boost.Spirit grammar in its own file (getting flex/bison working on Windows is *lots* of fun…I'll take Boost TYVM)).

[1]A fun one:

struct A { A(int) { /* … */ } int a; };
typedef float B;
int main(int argc, char**) { A a = (A)argc; B b = (B)argc; }

The A ctor gets called here where B is a C-style cast.

Day: GNOME OS

Posted Aug 8, 2012 20:20 UTC (Wed) by nix (subscriber, #2304) [Link]

I don't see how that's an incompatibility with C. struct A has a constructor, so it's not a POD type and can clearly not exist in C at all.

I'd not call implicitly calling constructors on casts to be much of a wart: if you didn't call the constructor, you'd end up with a non-initialized object and break things. The only alternative (as implemented if you declare the constructor explicit) is to ban a cast in that situation entirely, which means you make the casts to A and B look different merely because one is a POD type and the other is not, which is an implementation detail which the users of the types should not have to know.

Implicit conversions *are* full of horrible warts (such as the crudeness of the no-implicit-conversion-chains rule and *everything* about the syntax of 'operator random-typename'), but this is not one of them.

Day: GNOME OS

Posted Aug 8, 2012 20:30 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

It's not a compatibility with C issue, but it happens because C++ tried to be fully C compatible. If you're doing C casts in a template or something, it acts differently based on whether the template type is POD or not. If C++ had just said "we don't support C casts" this wouldn't be an issue. Plus, if you do rely on C casts for some (C++ POD) struct for some reason, you need to document the struct that it needs to stay a POD struct.

I really would have liked 'implicit' to be the keyword rather than 'explicit' as well, but alas…

Day: GNOME OS

Posted Aug 8, 2012 23:01 UTC (Wed) by nix (subscriber, #2304) [Link]

I think everybody agrees with you on that last point (and perhaps similarly for 'virtual', though changing that to 'nonvirtual' would violate the 'you don't pay for what you don't use' principle, so perhaps not), but such is the backward-compatibility burden...

Day: GNOME OS

Posted Aug 8, 2012 23:47 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

Not sure I feel the same about virtual because of the "only pay for what you use" principle. Another thing: something like a 'delayed const' (similar to 'final' in Java IINM) so that you can modify a variable and then 'constify' it so that it doesn't change after that point (something the compiler could enforce rather than assignment to a const& and relying on people to not use the pre-const& variable after).

Day: GNOME OS

Posted Aug 10, 2012 7:49 UTC (Fri) by nix (subscriber, #2304) [Link]

The 'delayed const' sounds like a finer-grained 'mutable'.

(But don't mention Java. Java's lack of constness is *awful*. More than once I have introduced horrible bugs because I accidentally modified a hash key due to the silent aliasing and lack of const of java.util.Map -- meanwhile such bugs never ever happen in the STL, not due to its nifty space-age genericity, but simply because its data structures copy the types handed into them, and won't give you something back that shouldn't be modified without a const on it. For that matter I have written data structures in poor old crude C with the same 'always copy, use const' rules as the STL, and *they* never suffered from this either.)

Day: GNOME OS

Posted Aug 10, 2012 8:10 UTC (Fri) by jezuch (subscriber, #52988) [Link]

> But don't mention Java. Java's lack of constness is *awful*.

Yes, that's one of the very few features that I truly miss in Java. There are workarounds like defensive copies and immutable wrappers but they're no fun.

Day: GNOME OS

Posted Aug 10, 2012 17:42 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

Also typedefs. I hated using Strings for everything and 5 parameters all of String to Android APIs means having to look up what the order is. At least the ordering is consistent where I used it (unlike, e.g., PHP)

Day: GNOME OS

Posted Aug 10, 2012 10:57 UTC (Fri) by jwakely (subscriber, #60262) [Link]

If C++ hadn't supported C casts (or had used a FFI for C interop, as you suggested above) it would never have achieved the success it enjoys today, which only happened by building on C's popularity and success. C compatibility is sometimes a millstone around the neck of C++ now, but without it this discussion probably wouldn't even be happening.

Without supporting C-style casts you couldn't write something as simple as this and have it be valid in both C and C++:

  int* p = (int*)malloc(n*sizeof(int));
It's the right design for a C-style cast to invoke a user-defined conversion if one exists, for the reasons nix gives. Why would you want to use C-style casts in templates anyway? Code in templates doesn't need to be C-compatible. You can't cast between arbitrary POD types anyway, in C or C++. Can you give an example that shows what you mean?

Day: GNOME OS

Posted Aug 10, 2012 11:09 UTC (Fri) by hummassa (subscriber, #307) [Link]

You can't c-cast from a POD type to another, but you can c-cast from a pointer-to-any-type to another (even if you have to cast to void* in the middle).

Day: GNOME OS

Posted Aug 10, 2012 11:18 UTC (Fri) by jwakely (subscriber, #60262) [Link]

Was mathstuf's statement "it acts differently based on whether the template type is POD or not" talking about casting pointers?

Day: GNOME OS

Posted Aug 10, 2012 14:59 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

You can always do:
>int *p = reinterpret_cast<int*>(malloc(n*sizeof(int))

Day: GNOME OS

Posted Aug 10, 2012 15:51 UTC (Fri) by jwakely (subscriber, #60262) [Link]

How would that be valid C?

Day: GNOME OS

Posted Aug 10, 2012 16:54 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

It's not, and that's the point. C++ could have avoided lots of warts caused by C-compatibility without losing in functionality.

Day: GNOME OS

Posted Aug 8, 2012 20:16 UTC (Wed) by nix (subscriber, #2304) [Link]

* Fragile ABI. libstdc++ ABI is partially different when using -std=c++11, so combining C++11 code bases with older code bases is fragile.
Jonathan Wakely pointed out recently that this is not true as of G++ 4.8: this has been backported to GCC 4.7.2+ as well (making 4.7.1's C++11 ABI incompatible with 4.7.2's, but anyone expecting a stable C++11 in GCC 4.7, the first version to have C++11 support at all, is living in a fantasy world in my opinion).

Day: GNOME OS

Posted Aug 9, 2012 15:22 UTC (Thu) by arafel (guest, #18557) [Link]

Maybe. I'm not convinced it's an unrealistic desire to retain compatibility across minor version changes, personally - if you're breaking the ABI then don't call it 4.7.x.

But I try hard not to use C++, so from a personal point of view it doesn't affect me that much. ;-)

Day: GNOME OS

Posted Aug 9, 2012 19:45 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

Since a minor version bump is more likely to be done in a "stable" distro, fixing 4.7 so that it's compatible with other version series is likely better than keeping 4.7.x incompatible forever. Of course, this only matters when -std=c++11 is in effect, so the problem is unlikely to manifest unless 4.7.1 is the last release in some popular EL distro.

Day: GNOME OS

Posted Aug 10, 2012 15:22 UTC (Fri) by slashdot (guest, #22014) [Link]

Wow, awesome.

Thank god that there are still some sane people in this world.

When some idiot from GCC announced that they wouldn't even try to keep a compatible ABI, I thought the GNOME3 disease had taken hold over there too, and all hope was lost, and it's great to hear the outbreak has instead been contained.

I mean, being able to compile any subset of a C++98 program as C++11 is an absolutely essential feature for obvious reasons, and not being able to use, say, foreach or auto without changing a program's ABI would be totally insane.

Day: GNOME OS

Posted Aug 10, 2012 15:44 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

The standard actually changed the ABI for std::string and std::list (possibly some others). The fix involves adding an attribute to help choose between the new and old ABI versions of classes. I can't find the blog link I read that on right now though.

From [1]:

> GCC versions 4.7.0 and 4.7.1 had changes to the C++ standard library which affected the ABI in C++11 mode: a data member was added to std::list changing its size and altering the definitions of some member functions, and std::pair's move constructor was non-trivial which altered the calling convention for functions with std::pair arguments or return types. The ABI incompatibilities have been fixed for GCC version 4.7.2 but as a result C++11 code compiled with GCC 4.7.0 or 4.7.1 may be incompatible with C++11 code compiled with different GCC versions and with C++98/C++03 code compiled with any version.

[1]http://gcc.gnu.org/gcc-4.7/changes.html

Day: GNOME OS

Posted Aug 10, 2012 15:58 UTC (Fri) by jwakely (subscriber, #60262) [Link]

> The standard actually changed the ABI

No. The standard doesn't mention an ABI.

Some implementations' std::string and std::list have always been compatible with the new requirements, so don't have to change.

So more accurately, the C++11 standard requires certain properties of std::string and std::list which are incompatible with GCC's existing implementations of those types.

> I can't find the blog link I read that on right now though.

Maybe you mean my comment that nix refers to in the grandparent post?

Day: GNOME OS

Posted Aug 10, 2012 16:08 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

Ah, that makes more sense.

And yes, that blog post. Thanks :) .

Day: GNOME OS

Posted Aug 10, 2012 16:01 UTC (Fri) by jwakely (subscriber, #60262) [Link]

There was never a question of foreach or auto changing the ABI, the incompatibilities are restricted to the library. Try to understand the facts before spouting rubbish and calling people idiots.

That idiot might be the same person who reported the news you applaud now. You're welcome by the way. Now when are you going to do something for me in return other than lower the level of discourse on LWN?

Day: GNOME OS

Posted Aug 10, 2012 17:02 UTC (Fri) by slashdot (guest, #22014) [Link]

Except that I'm pretty sure auto or foreach required --std=c++11 to be used, which also resulted in some macros getting defined (__GXX0X_EXPERIMENTAL__ or something like that), which in turn changed the size of std::list in the STL headers due to an #ifdef.

As far as I can tell, this is what they fixed in GCC 4.7.2 (apparently by reverting the changes, with a plan to make it a separate switch along with the ability of C++98 and C++11 ABIs to coexist), and the rubbish is the one you just spouted.

I'm not sure who the "idiot" was, but I remember reading in GCC bugzilla someone who argued that the situation described above was totally fine, while any reasonable person would instead think that it had to be avoided at any cost, as they fortunately did later.

Obviously someone who does that definitely deserves to be insulted, since he first insulted and damaged all its users with such a decision.

Day: GNOME OS

Posted Aug 10, 2012 17:25 UTC (Fri) by nix (subscriber, #2304) [Link]

Sheesh. You just don't take a hint, do you? The implementors of all this stuff - the mysterious impersonal 'they' you refer to -- are Paolo Carlini and Jon Wakely (y'know, the guy you're responding to). Neither of them are any sort of idiot, though I suspect from your failure to notice the authorship of these patches despite having received multiple direct links to them that *you* might need a major upgrade of your observational skill.

Day: GNOME OS

Posted Aug 10, 2012 17:38 UTC (Fri) by slashdot (guest, #22014) [Link]

Well, definitely they were idiots when they introduced the ABI change in question and defended it on Bugzilla etc.

Which is really hard to argue against, since they then had to revert the change in the middle of a stable series!

Anyway, I guess the important thing is that they returned to sanity, although obviously it would have been better for that to happen before releasing 4.7.0.

Day: GNOME OS

Posted Aug 10, 2012 17:50 UTC (Fri) by slashdot (guest, #22014) [Link]

BTW, the REAL idiots here are the guys in the C++ comittee who released a broken unimplementable standard (or alternatively, a standard without a full compatibility goal, which is even worse), despite having had 13 (!!!) years to fix it.

The gcc developers pretty much merely slavishly followed that idiocy without questioning, until they realized their mistake.

Day: GNOME OS

Posted Aug 10, 2012 18:30 UTC (Fri) by nix (subscriber, #2304) [Link]

Er, you do realise that the C++ Standard, following the original STL, has imposed time and space complexity constraints on various parts of the library for a very long time? They're essential, because those constraints are the only difference between some of the Standard's data structures.

This was just a new constraint, which was unfortunately incompatible with the existing implementation of the list<> in GCC, and it was impossible to change it without breaking backward compatibility. (One problem with templated data structures is that a lot of things you wouldn't expect to be ABI concerns actually are, because they are included in programs using them via template expansion.)

Deciding whether to violate the language standard or piss off your users is an unpleasant fork to be in -- but it's not the committee's fault either, because this sort of change is what language standard revisions have always done. C99 broke some valid C89 code: C11 breaks some more. It's just that the set of GCC-compiled code that got broken by a fully conformant implementation of the C++11 list<> was rather large...

Day: GNOME OS

Posted Aug 10, 2012 19:13 UTC (Fri) by slashdot (guest, #22014) [Link]

> This was just a new constraint, which was unfortunately incompatible with the existing implementation of the list<> in GCC, and it was impossible to change it without breaking backward compatibility

And that's the problem.

Adding the new constraint by the C++ committee was simply asinine, especially, since you lose O(1) list splicing (and you can keep the size yourself with C++98 std::list, but can't do O(1) splice yourself with C++11 std::list), and because at least one existing implementation could not provide it while keeping compatibility.

They should have added a new type if they wanted C++ to have a linked list with O(1) size().

BTW, they also broke multithreaded programs using std::list, since unless the size field is updated with atomics (which kills performance on several archs), it's no longer true that you can add to the head of a non-empty list in a thread and to the tail in another thread, which would work in C++98 libstdc++.

As for the GCC, I think it should need a separate option to enable ABI-breaking C++11 changes, and --std=c++11 should only enable the backwards compatible C++11 subset, which appears to be what they hint at in the recent announcement.

C++11 is not fully implemented anyway, so that's not an issue for now, and perhaps in the meantime the standard can be revised to revert the changes.

Day: GNOME OS

Posted Aug 10, 2012 19:28 UTC (Fri) by juliank (subscriber, #45896) [Link]

If I had to guess, I'd say that the O(1) size() thing was introduced to the standard by Microsoft.

Day: GNOME OS

Posted Aug 10, 2012 19:42 UTC (Fri) by juliank (subscriber, #45896) [Link]

OK, it seems to be pushed by Apple via proxy, not Microsoft, as far as I can tell.

Day: GNOME OS

Posted Aug 10, 2012 20:02 UTC (Fri) by foom (subscriber, #14868) [Link]

Slashdot: You've been told more than once to stop with such insulting. It is exceedingly inappropriate. Maybe it's expected behavior on your namesake website, but not here.

The change was a mistake, the defense of it was wrong. That STILL doesn't mean you get to call the people involved idiots.

Day: GNOME OS

Posted Aug 10, 2012 17:30 UTC (Fri) by ris (editor, #5) [Link]

> Obviously someone who does that definitely deserves to be insulted, since > he first insulted and damaged all its users with such a decision.

It is not at all obivious that anyone needs to be insulted just because they do something you disagree with. Please refrain from insulting people on this site. This is your second warning.

Day: GNOME OS

Posted Aug 10, 2012 17:21 UTC (Fri) by nix (subscriber, #2304) [Link]

I do wonder if there's anyone on Earth slashdot won't call an idiot or a moron. There certainly doesn't seem to be any need for actual evidence before accusations are launched.

Day: GNOME OS

Posted Aug 13, 2012 11:33 UTC (Mon) by nye (guest, #51576) [Link]

>I do wonder if there's anyone on Earth slashdot won't call an idiot or a moron. There certainly doesn't seem to be any need for actual evidence before accusations are launched.

But it's the open source way, and is widely (though not universally) supported here whenever the question comes up of whether this is an appropriate way to behave.

Standards are great, double standards doubly so.

(BTW I'm not being flippant - this is exactly the standard of behaviour that's considered normal and expected in the open source communities I look at. Compared to debian-devel it's positively gentlemanly.)

Day: GNOME OS

Posted Aug 13, 2012 16:39 UTC (Mon) by apoelstra (subscriber, #75205) [Link]

> But it's the open source way, and is widely (though not universally) supported here whenever the question comes up of whether this is an appropriate way to behave.

I'm sure you could find many examples of open-source communities where rudeness and flamefests are considered appropriate behaviour. You could also find examples where the opposite is true.

But however "widely supported" this attitude is in the greater open source world, it is my experience that it's not supported here on LWN, which is (for the most part) a very polite, civil, intelligent place for discussion.

Day: GNOME OS

Posted Aug 8, 2012 7:34 UTC (Wed) by slashdot (guest, #22014) [Link]

I think the reason is that mobile non-Android Linux has never been backed by a company who totally relied on it and was investing as much money as Google+partners and Apple probably did.

IIRC the only phone maker backing it was Nokia, but their attention was mostly towards Symbian.

Also, writing everything but the kernel from scratch yourself like Google and Apple did probably gives a better result than adapting existing components, as long as you have a huge budget allowing you to hire as many people as needed.

And finally there's the fact that Google decided to write the Android userland instead of going with GNOME/KDE, which is probably because they thought that Java was a much better language than C/C++ for desktop development, because they thought that designing specifically for mobile would give huge benefits.

Given Android1s success, Google's decisions were probably right, so it's not clear why doing differently would work now.

Day: GNOME OS

Posted Aug 8, 2012 8:08 UTC (Wed) by drag (subscriber, #31333) [Link]

> I think the reason is that mobile non-Android Linux has never been backed by a company who totally relied on it and was investing as much money as Google+partners and Apple probably did.

There are a lot of terrible things wrong with 'non-Android Linux' currently. It existing long before Android ever did and has had decades of development beyond what Apple did with iOS. As it turns out it appears to have been easier for Google and friends to avoid distributions and 'non-Android Linux' completely and base a new platform on Java. This points to a serious problem.

> IIRC the only phone maker backing it was Nokia, but their attention was mostly towards Symbian.

Nokia at the time of their adoption of Linux owned well over 75% of the smart phone market, world-wide. They were _THE_ smart phone maker. Nobody else came close. In addition to Nokia the Meego/Meamo initiatives had a corporate support from a number of backers, including Intel... which is just about as big as you can get and not be Microsoft or Apple. Besides that there are various companies that were interested in it for non-smartphone applications such as tablets or vehicle entertainment centers.

I don't think that lack of capital is a core issue here. Nokia still has plenty money and did have plenty talent. It's simply mismanagement. Google's various 'android partners' have no loyalty to Google or the platform. Nokia had several significant 'Symbian partners', too. They would of been just as willing to use Meamo/whatever as much as Android if it worked out well. I am sure they are far more interested in a working platform then swooning over the idea of 'davlik' or whatever.

Day: GNOME OS

Posted Aug 8, 2012 8:58 UTC (Wed) by krakensden (subscriber, #72039) [Link]

> In addition to Nokia the Meego/Meamo initiatives had a corporate support from a number of backers, including Intel...

The tortured history of the two projects, including multiple throw-everything-away-and-start-from-scratch moments on both the Intel and Nokia ends, demonstrates that they weren't something management was serious about or cared about.

Day: GNOME OS

Posted Aug 8, 2012 16:45 UTC (Wed) by oak (guest, #2786) [Link]

Are there any studies about companies suffering from ADHD? And how to cure them?

Day: GNOME OS

Posted Aug 8, 2012 17:35 UTC (Wed) by mspevack (subscriber, #36977) [Link]

And Red Hat... actually actively threw all their consumer users under the bus with the Fedora rebranding.

Argue whatever you like about what Red Hat should or shouldn't do regarding GNOME, but it seems a bit silly to play a nearly 10-year-old card as part of that argument.

To me, it seems that the modern Fedora is one of the distros that is a big supporter of the entire GNOME 3 world. The fact that some of the GNOME 3 developers are employed by Red Hat is clearly part of the reason for that.

Day: GNOME OS

Posted Aug 8, 2012 6:26 UTC (Wed) by ovitters (subscriber, #27950) [Link]

I gather you never tried jhbuild. Making it more easy to build GNOME should be applauded.

Day: GNOME OS

Posted Aug 8, 2012 6:45 UTC (Wed) by drag (subscriber, #31333) [Link]

There also appears to be other fun problems they would like to solve besides making jhbuild not-suck

Example of trying to deal with a problems related to updating Linux software:
http://neugierig.org/software/chromium/notes/2011/08/zygo...

Day: GNOME OS

Posted Aug 8, 2012 8:07 UTC (Wed) by krake (subscriber, #55996) [Link]

Interesting link.

I am not sure I understand all details, but it sounds like the Windows or OS X app stores do not overwrite the files programs when they apply updates.

Do they transition between versions on next boot/login?
Or do they shut applications down when they update them?

Day: GNOME OS

Posted Aug 8, 2012 8:40 UTC (Wed) by drag (subscriber, #31333) [Link]

> I am not sure I understand all details, but it sounds like the Windows or OS X app stores do not overwrite the files programs when they apply updates.

Not sure how it works for either platform. I am very much a Linux guy and have ignored other platforms.

With Windows you have locks on the files you have open. So at least you can know if files you are using have been changed when you fork+exec stuff. With the application handling updates, like Windows versions of Firefox and Chrome do, then that gives you a lot of control. You just launch a update process and tell the user to stop the application before the application is applied. With Linux not allowing regular users to do updates and plus having the update process entirely outside of the control of the application this sort of functionality is probably impossible to replicate.

It is probably also worth examining closely how Microsoft has gotten to mitigate the problems surrounding 'DLL Hell' for the majority of use cases. Versioning issues can and do certainly occur in Windows, but for the majority of users it isn't going to a problem unless their system has been around for a very long time or they are dealing with very old and creaky software.

Going back to 'Gnome OS'...

It seems like the 'Gnome OS' approach that is currently being explored is to avoid the use of traditional Linux package management and utilize some modern Linux file system tricks to make it possible to install applications and much of their dependencies in unique directories while minimizing the amount of duplicated files between application directories.

Here is one of their initiatives right now:

https://live.gnome.org/OSTree/

> Fundamentally, OSTree is designed with the idea that having multiple "roots" installed is a normal condition, and is optimized for it.

On the surface it sounds similar to what I, and I believe many others, typically do to deal with installing video games on Linux. Since most of the time most 'native games' I want to play are not packaged directly for my distribution I very much prefer to download tarballs of binaries then to build them. Even if I build them I still want them separate from my 'OS'. So typically I just install everything in my ~/.local/ directory and launch from from scripts via the command line. Other people may have ~/apps or ~/games, but it's similar.

Also this is the approach taken by things like the old Cedega or the newer 'Playonlinux' stuff for installing non-native games. Each game gets their own tailored wine versions and environment since best compatibility with the distro-installed wine version is unlikely. They have many 'multiple roots' for each game's specific windows environment. This seems to work out really well for what is normally a very unpleasant/difficult activity (installing windows games on Linux)

http://www.playonlinux.com/en/

I haven't heard about this before the above mentioned blog post so what I said in regards to Gnome's approach is likely largely incorrect.

Day: GNOME OS

Posted Aug 8, 2012 8:58 UTC (Wed) by krake (subscriber, #55996) [Link]

"With the application handling updates, like Windows versions of Firefox and Chrome do, then that gives you a lot of control."

Of course. But the article doesn't cover privately controlled installations but how to cope with app store based updates.
Since they ran into a problem on Linux, it would have been interesting to know how the Windows or OS X app stores handle this.

Or maybe the article was misleading in that it is actually not about Linux being more difficult to handle but app store based application updates vs. privatly controlled ones.
In this case it would be strange that the two different approaches were not described for the same platform.

One has to wonder if the author's intent was to simply bash Linux by using a tightly vendor controlled installation on the other platforms and a store controlled installation on Linux, making the latter more complex to handle.

Of course this would be absurd but I've seen similar things way to often to completely rule it out.

Day: GNOME OS

Posted Aug 8, 2012 10:10 UTC (Wed) by drag (subscriber, #31333) [Link]

The author's intent was to describe why they have to use a zygote process on Linux to watch over spawning new processes and why they don't need to jump through all the same hoops do that in Windows or OS X.

Another way to put it, more or less:

Due to Windows habit of locking files it has forced people to use a model of installing that avoids file clobbering issues present in Linux. Something else magically happens on OS X.

It seems to do the same thing in Linux with a system-wide package manager you would need a package manager that is aware of the processes that users are running, installs the software update to a alternate directory, sends a notification to users to shut down the application, and when they do that then rename the new directory over the old one.

Or something like that.

I am very interested in how iOS/OS X handles application updates through the app store. The blog posted hinted at versioning directories in the app bundle, but I have no clue what happens with iOS and such.

Day: GNOME OS

Posted Aug 8, 2012 11:36 UTC (Wed) by krake (subscriber, #55996) [Link]

"The author's intent was to describe why they have to use a zygote process on Linux to watch over spawning new processes and why they don't need to jump through all the same hoops do that in Windows or OS X."

Well, he clearly failed on the second part, since the posting does not contain enough information why that is not a problem on Windows and OS X.

For example it is missing the information krakensden added, i.e. that Windows can schedule a rename to the next reboot, allowing the app store to schedule replacement of files but on the downside also requiring system restart.

As I said it I don't want to assume the worst but it smelled a lot like comparing different types of upgrade mechanisms

Day: GNOME OS

Posted Aug 8, 2012 14:19 UTC (Wed) by drag (subscriber, #31333) [Link]

Well the guy doesn't know how they really do it on OS X.

And yes it is comparing update methods. They need to do what they do in order to deal with some of the bad aspects of how Linux installs packages.

They could ignore that completely and have each user install Chrome in their home directory, but apparently it is easier to write a bunch of code to work around rpm/deb-style package management then to try to convince Linux users to not depend on rpm/deb for installing and updating Chrome/Chromium.

He also seems to indicate that it's not going to be a issue with them on Chromium OS.

Day: GNOME OS

Posted Aug 8, 2012 14:40 UTC (Wed) by krake (subscriber, #55996) [Link]

"And yes it is comparing update methods."

Well, than the blog posting is without merrit.
If you specifically chose a technique for something you should understand its properties. And then you deal with those properties. Doesn't make any sense to complain about having to deal with them when comparing with a technique that does not have them.

Like complaining that parallel processing with child processes needs extra work when accessing shared data and stating that multi threading would make that way easier.

"They could ignore that completely and have each user install Chrome in their home directory..."

Or globally.

"...but apparently it is easier to write a bunch of code to work around rpm/deb-style package management then to try to convince Linux users to not depend on rpm/deb for installing and updating Chrome/Chromium."

Well, if it is easier to deal with app store limitations than not to be in the app store than that is a conscient choice. Complaining on how easy it would have been not to be in the app store is just whining.

So marketing (or managment) decided that being in the app store outweights extra engineering effort. Deal with it!

Day: GNOME OS

Posted Aug 8, 2012 16:19 UTC (Wed) by cmccabe (guest, #60281) [Link]

The issue is that they don't want to have to restart Chrome/ium after an update. And they don't want to deal with version skew between different files. Their solution seems reasonable to me overall.

Day: GNOME OS

Posted Aug 8, 2012 16:24 UTC (Wed) by drag (subscriber, #31333) [Link]

Seems that he thinks it's much easier task to accomplish if they didn't have to deal with Linux apt/rpm style updates.

Day: GNOME OS

Posted Aug 9, 2012 8:31 UTC (Thu) by krake (subscriber, #55996) [Link]

True, but they decided that getting into the app stores made the additional engineering costs acceptable.

They could have avoided the issues by going the route of a stand-alone installer but obviously found it more viable to do it the other way.

Day: GNOME OS

Posted Aug 8, 2012 12:40 UTC (Wed) by Mog (subscriber, #29529) [Link]

Something I don't understand : why anyone would expect a browser session to continue fine after an update ?
Windows gave us the expectation of a reboot after IE updates (I know, this may not be mandatory nowadays but old habits die slowly).
On my Linux boxes, I close all applications, especially browsers, before running 'yum update'.

Day: GNOME OS

Posted Aug 8, 2012 13:17 UTC (Wed) by nix (subscriber, #2304) [Link]

Really? That sounds terribly disruptive. I never close a thing before doing updates (unless the update is huge, e.g. pushing all of KDE from 4.7 to 4.8 or something like that, in which case I generally log in again afterwards), and have never had trouble.

Day: GNOME OS

Posted Aug 8, 2012 14:10 UTC (Wed) by drag (subscriber, #31333) [Link]

> Something I don't understand : why anyone would expect a browser session to continue fine after an update ?

Well the application or user is given no notification that a update was performed for most (if not all) Linux systems unless the user is the one that did the update itself.

If it's a single user environment then it's not that big of deal, but I suppose it can cause headaches unless the administrator makes sure to upgrade the system while everybody is logged out.

Day: GNOME OS

Posted Aug 8, 2012 14:43 UTC (Wed) by krake (subscriber, #55996) [Link]

If the software depends on anything not changing after startup, it could monitor those files.
I believe that this is possible nowadays. Might even be possible to monitor the application's installation directory as a whole

Day: GNOME OS

Posted Aug 8, 2012 16:22 UTC (Wed) by drag (subscriber, #31333) [Link]

yeah. Inotify and such. I believe that sort of thing is what they Zygote process for (as mentioned in the blog post), which is extra steps that they don't have to do on other systems.

The code used to do such things is suppose to be rather ugly, but unfortunately Google has terminated it's code search stuff and thus the links from his post showing what Chrome does is broken. I don't have time to hunt down the details myself right now.

Day: GNOME OS

Posted Aug 8, 2012 20:08 UTC (Wed) by nix (subscriber, #2304) [Link]

Nah, the Zygote process does nothing as crazy as inotify. It's just a run mode of the chrome binary where it does nothing but listen for requests to fork off children to do other work. Thus, it ensures that those children are all the same instance of the same binary, so are guaranteed to be able to engage in IPC with each other (and with the master browser process) smoothly.

The thing is, a forking architecture like this is a good architecture for other reasons, compared to a plain exec() architecture. Among other things, it means that relocation happens only once, so it saves memory because pages dirtied by relocations are dirtied only once, and it saves time because relocation happens just once, at Chrome startup (an important consideration when the binary is 110Mb). KDE 3 used exactly this architecture just to minimize relocation overhead.

Again, this thing is *five hundred lines*. It's *trivial*. I've written similar things in under a day. And people are proposing massive invasive changes to every program storing state in /etc, and massive invasive changes to the way updates are carried out, to save on the terrible overhead of writing something tiny like this. Why? I am baffled.

Day: GNOME OS

Posted Aug 8, 2012 22:26 UTC (Wed) by walters (subscriber, #7396) [Link]

<p>Why don't you go out and patch every application to do it then? I think you'll quickly find that it's <b>insanely tedious</b> for application authors to have to keep a file descriptor open on every file they use.</p>

<p>What's even better - it's <b>still racy</b>. If the user launches an application while an update is happening, the app can get half of the old files, and half of the new. There is no way to solve this without coordination at every layer of the stack.</p>

Day: GNOME OS

Posted Aug 8, 2012 23:00 UTC (Wed) by nix (subscriber, #2304) [Link]

Have you responded to the wrong comment? There's nothing in the zygote model requiring file descriptors to be kept open to anything at all, and it's not racy if you keep each application in its own root (as nixos does: I'd agree this is one of the things it gets right), because the binaries and non-shared datafiles for a given package are never overwritten.

In fact with only a few exceptions (e.g. Perl if you want to use CPAN), you can mark such subtrees immutable and nothing whatsoever breaks. (I've been doing this for years.)

Yet again, this seems like a massive invasive change for very nearly undetectable benefit -- and it still doesn't solve the only instance of this problem that I can ever recall encountering, the 'updated application state in your home directory breaking downgrade' problem.

It's a shame I'll not be at LPC or we could have a good argument over this :)))

Day: GNOME OS

Posted Aug 9, 2012 15:41 UTC (Thu) by arafel (guest, #18557) [Link]

I think you might have misread the blog post:

This process opens every file we might use and then waits for commands from the main process. When it's time to make a new subprocess we ask the helper, which forks itself again as the new child. By virtue of always forking from the same initial process, we guarantee that we are always running the same code; even if the files we opened are replaced by a system update our handle on them is the handle for the previous file.

Day: GNOME OS

Posted Aug 10, 2012 8:16 UTC (Fri) by nix (subscriber, #2304) [Link]

Oh yes, true enough. Of course the most important part of this is the 'always running the same code' part. You don't have to hold the files open: if there are lots of little ones you might prefer to suck them into memory instead.

(Obviously this model will not apply to everything, but it does in fact apply to a lot. You need an abstraction around file I/O to do it, but Chrome already *has* that, and thanks to libio and open_memstream() anything can get it quite easily, without major rewrites.)

Day: GNOME OS

Posted Aug 8, 2012 16:48 UTC (Wed) by endecotp (guest, #36428) [Link]

> I am very interested in how iOS/OS X handles application
> updates through the app store.

On iOS, if you install an update to an app from the store, then any currently-running instance of the app is killed first.

Only one app is "foreground" at any time on iOS, so when the App Store app is in the foreground, the app being upgraded cannot be. When an app is backgrounded, it is told that it is going in to the background and it is expected to save its state. It might eventually be resumed but it could be terminated without any further notice due to power-off, low memory, etc. So the case of an update is not special.

I don't know how it works on the Mac, where presumably the app being upgraded might still have windows visible. My guess is that it is killed with some notice first.

Day: GNOME OS

Posted Aug 9, 2012 8:39 UTC (Thu) by krake (subscriber, #55996) [Link]

"I don't know how it works on the Mac, where presumably the app being upgraded might still have windows visible. My guess is that it is killed with some notice first."

I wouldn't be so sure. The blog indicated that Chrome wants to be running during and after the upgrade and it said Linux makes that difficult and Windows and OS X don't.

Therefore we msut assume that the Mac store update process allows applications to continue to run. There is just no confirmation on that yet and not details how it does it.

Day: GNOME OS

Posted Aug 9, 2012 9:30 UTC (Thu) by hummassa (subscriber, #307) [Link]

this is probably because the Mac upgrade process changes the whole /Applications/Google\ Chrome directory and the old application + the old shared objects is running from the old directory, so you don't have the problem you usually have *during* an apt-get dist-upgrade that if your running applications dlopen(), they do that with the *new* libraries (possibly inconsistently with what they are expecting).

Day: GNOME OS

Posted Aug 8, 2012 9:00 UTC (Wed) by krakensden (subscriber, #72039) [Link]

> With Windows you have locks on the files you have open

Indeed. The Windows equivalent of rename(2) actually takes a flag that schedules the move after the system restarts, which makes lots of install/upgrade activities kind of trivial.

Day: GNOME OS

Posted Aug 8, 2012 10:23 UTC (Wed) by slashdot (guest, #22014) [Link]

Really?

This is pretty much the worst feature of Windows.

It's absolutely horrible to not be able to replace files in use, when such an operation is clearly conceptually trivial as shown by Linux.

Don't copy it please.

The RIGHT way of solving the problem is not that, but it is:

1. Install applications in their own versioned directories instead of scattering their files all over
2. Add kernel support to unlink a directory, which once the last reference drops (or after reboot) causes recursive unlink of all its contents (or alternatively, use a daemon+initscript to do the same)
3. Make applications keep the their directory open as an fd (and by keeping a connection to the daemon if using that solution), and use openat() on that fd to open their files
4. Package removal works using the new kernel unlink feature, but the directory is still accessible via the application's fd and is physically deleted only when application is closed or reboot (due to #2 and #3)
5. Package upgrade works by removing the previous version as before, then creating a new directory with a different version number with the new one, then redirecting /usr/bin/APP to that directory.

Day: GNOME OS

Posted Aug 8, 2012 10:39 UTC (Wed) by hummassa (subscriber, #307) [Link]

> 2. Add kernel support to unlink a directory, which once the last reference drops (or after reboot) causes recursive unlink of all its contents (or alternatively, use a daemon+initscript to do the same)

Just move it to the an application-recyclebin on uninstall/upgrade. (3) becomes unneeded, (4) and (5) become moot. And you can rollback upgrades and uninstall easily. Empty/tidy the application-recyclebin on boot.

Day: GNOME OS

Posted Aug 8, 2012 11:36 UTC (Wed) by slashdot (guest, #22014) [Link]

Well, the problem is that systems can just never get rebooted, and anyway waiting for reboot is suboptimal.

So, you need either the kernel or a daemon that can notice the application files are no longer in use and can zap then quickly.

Not totally sure on the best mechanism for that, but it's definitely possible.

Day: GNOME OS

Posted Aug 8, 2012 13:16 UTC (Wed) by nix (subscriber, #2304) [Link]

Well, once applications fall out of use they never go back into use again (since new invocations will invoke the new one): so have a cronjob that periodically hunts across deleted applications for files no longer in use by anything, and deletes them. This won't be noticeable performance-wise because most deleted applications will be not-in-use the instant they are removed, so can be aggressively deleted.

(Personally, I keep my versioned per-app trees around for a month to allow for later downgrading. I have never had a single problem with the script that deletes them after that much time.)

Day: GNOME OS

Posted Aug 8, 2012 16:41 UTC (Wed) by rahvin (subscriber, #16953) [Link]

Wouldn't that cause a severe impact to battery life on battery driven devices? You want everything sleeping unless it's in active use, what you suggest would keep the CPU active even when the device isn't being used. Of course if we don't concern ourselves with battery driven devices it's not a concern.

Day: GNOME OS

Posted Aug 8, 2012 17:11 UTC (Wed) by drag (subscriber, #31333) [Link]

You'd only need to run it once a month or something like that. And there are numerous other cron jobs that perform tasks on Linux.

It wouldn't be difficult to put a logic into the cron job to check to see if it's on battery and delay until it's on the charger or above 80% charge or something of that nature.

Day: GNOME OS

Posted Aug 9, 2012 13:53 UTC (Thu) by etienne (guest, #25256) [Link]

Maybe simpler would be to install in a new directory and "play" with $PATH (or other environment variable) so that shells started before the install see only the previous version and shell started after the update see only the newer version?

Day: GNOME OS

Posted Aug 10, 2012 8:18 UTC (Fri) by nix (subscriber, #2304) [Link]

My old uni did something like this. It was fiercely annoying because it made it *impossible* to upgrade anything without logging out. (Not as annoying as having to reboot to upgrade, but nearly as much.)

Far better to symlink the new things into place in some shared tree. (Of course, symlinks have slight annoying semantic changes, so a few pieces of software need adaptation to this, though maniac stow and graft users like me have already done it for most stuff. If this was really Plan 9, we could just bind-mount everything into place in your per-user /bin, and have a command that refreshed all your /bin mounts when you wanted them refreshed, flash-updating you to the latest goodies but only when you wanted it.)

Day: GNOME OS

Posted Aug 10, 2012 9:20 UTC (Fri) by etienne (guest, #25256) [Link]

It should be possible to open a new xterm and get newly installed applications in that process group, but I do agree you cannot run the new applications from the global menu without logging out - unless there is a way to "refresh menus".

Day: GNOME OS

Posted Aug 8, 2012 14:27 UTC (Wed) by nye (guest, #51576) [Link]

This is so awful that changing it would be the single biggest improvement to Windows I can imagine.

Honestly, 99% of the solution would be simply to use a flag that performs the rename not on next reboot, but when all current locks on the file have been dropped.

The kernel needs to know that anyway, so it should be possible without some nasty polling daemon, and it would turn 'reboot system' updates into 'restart application' updates, which solves the problem for anything other than updating files belonging to system processes, for which it doesn't feel so unreasonable to have to reboot.

Each version of Windows requires fewer reboots than the last, so maybe there actually is a flag that does this and it's "simply" a matter of updating the entire world to use it(?)

(Ultimately that would provide similar update semantics to Linux, which might mean the same problem described up-thread unless some thought is put into it, but it *would* mean that MS get to keep the semi-mandatory locking they love so much)

Day: GNOME OS

Posted Aug 8, 2012 10:36 UTC (Wed) by nix (subscriber, #2304) [Link]

> Fundamentally, OSTree is designed with the idea that having multiple "roots" installed is a normal condition, and is optimized for it.
Yep, and they can't handle /etc, so they plan to give up and simply rewrite all applications to not use /etc for anything. Who needs systemwide configuration state anyway?

That's gonna fly.

Day: GNOME OS

Posted Aug 8, 2012 11:44 UTC (Wed) by walters (subscriber, #7396) [Link]

It is not true that /etc makes the current OSTree design unworkable. It just makes the downgrade/bisection story harder.

Day: GNOME OS

Posted Aug 8, 2012 13:13 UTC (Wed) by nix (subscriber, #2304) [Link]

Obviously you fix this by storing /etc in version control with something like etckeeper, branching it when you create a new subtree, and tying the branch names and subtree names together somehow.

This took me less than five seconds to think of, but *someone* thought that the problem was nasty enough to propose on the OSTree wiki the rewriting of all existing applications to not rely on /etc. Because that will be so much simpler.

Day: GNOME OS

Posted Aug 8, 2012 13:28 UTC (Wed) by walters (subscriber, #7396) [Link]

Let's be clear: for nearly all of the stuff on the wiki, "someone" is me =)

The page you're referring to is the *long term* plan. It's doable over time.

There are a variety of shorter term approaches, and I have an OSTree branch that in fact started on a "stupid merge" strategy like what you're describing.

Anyways, if you are interested in coding instead of commenting in a textarea, you can also join ostree-list@gnome.org - thanks!

Day: GNOME OS

Posted Aug 8, 2012 14:27 UTC (Wed) by walters (subscriber, #7396) [Link]

Also, for anyone planning to come to Linux Plumber's in San Diego, my talk there will focus on this:

https://blueprints.launchpad.net/lpc/+spec/lpc2012-boot-a...

Day: GNOME OS

Posted Aug 8, 2012 16:33 UTC (Wed) by cmccabe (guest, #60281) [Link]

I realize you have good intentions, but do you really think creating another competitor to RPM and DEB is a good idea? I think it's just going to increase fragmentation.

It seems like the feature you want (atomic updates) could be retrofitted to the existing systems. btrfs supports the concept of transactions at the filesystem level, which is exactly what you need here.

I'm pretty sure that the RPM guys would be overjoyed to have someone sane take over as the upstream maintainer. Please, please, please, think before you reinvent the wheel.

Day: GNOME OS

Posted Aug 8, 2012 16:53 UTC (Wed) by walters (subscriber, #7396) [Link]

I describe the BTRFS issues here: https://live.gnome.org/OSTree/RelatedProjects

Basically however you slice it, you need a way to have two operating systems installed. Whether they're squirreled away in a BTRFS snapshot or unpacked as hard links is really an implementation detail.

The *real* challenges are around configuration management, how you present this to the system administrator, etc. For example, it's clearly desirable if the system software management tool can tell you stuff like "you have N OS images installed, the additional snapshots are taking up XX megabytes of disk space compared to the current".

To do that kind of thing, you need something aware of *both* the rpm/deb state and the BTRFS state.

Furthermore, one huge advantage of the current OSTree design (that I need to promote more on the wiki) is that it parallel installs inside your existing distribution - you don't need to switch disk formats. All you sacrifice is disk space.

You don't have access to that package of bioinformatics software in the latest GNOME OS? No problem, reboot into your regular host distribution and use it. Switch back when you want to see the latest GNOME.

Day: GNOME OS

Posted Aug 8, 2012 21:10 UTC (Wed) by cmccabe (guest, #60281) [Link]

There are two issues here:
1. Some package managers don't atomically put their new sets of files into place. This could cause problems in the event of an unexpected power cut.
2. Current package managers update application files while those applications are still open.

#1 can (probably) be solved just by batching everything up that rpm or deb does into a single btrfs transaction.

#2 is a little more subtle. Most update systems that I'm aware of don't even try to solve this problem. For example, Android forces you to restart your apps after you've upgraded them. (Application restarts are less of a big deal in Android, though, because of how they designed process lifecycle.)

In general, it seems sufficient to restart most applications. Maybe a flag could be introduced indicating whether the application needs to be auto-restarted, or whether it chooses to handle updates at the application level (by using inotfy, or by keeping a bunch of fds open like Chrome does).

Please don't bother re-inventing the chroot wheel for GNOME. I know how to set up chroots and virtual machines, thanks very much.

Day: GNOME OS

Posted Aug 8, 2012 17:01 UTC (Wed) by walters (subscriber, #7396) [Link]

Also, my GUADEC 2012 presentation covers some of this: http://people.gnome.org/~walters/guadec-2012-building-gnome/

(It's now on the wiki too)

Day: GNOME OS

Posted Aug 8, 2012 19:54 UTC (Wed) by nix (subscriber, #2304) [Link]

[Warning: this is a rant.]

As far as I can see, the 'stupid merge' strategy -- or a smarter one with custom merge drivers -- is the only sane approach. What's the alternative? As far as I can see, there is none other than some bizarre intent to avoid all systemwide configuration forever, which, as I said, is just not going to fly with virtually any upstream you don't already control.

Any system that retains configuration state in any way will retain the problem of merging it -- and systemwide state isn't the largest problem in any case, it's per-user state, which is far more mutable and often contains references to data that must not be lost (be that emails or financial info). What are you going to do, wipe everyone's dotfiles whenever a downgrade takes place? Keep the config with the earlier trees, so if you make a change after upgrading it's *lost* on downgrade? Neither seems even slightly sane to me.

What OSTree is proposing is somewhat unclear, but appears to require rebooting on *every single package upgrade* so as to switch into a new chroot containing that package. That means several times a day for me. Not a bloody chance am I letting something like *that* near any of my systems outside a VM: it is transparently ridiculous and optimizing for a very few programs that might need to take extra measures to avoid being broken by updates happening underneath them, like Chromium, yeah, already *did*, so it is clearly not impossible: the zygote is also not exactly rocket science, weighing in at well under a thousand lines of code).

Now maybe laptops don't mind being rebooted this often, but a server with NFS-mounted home and scads of daemons and remote users relying on it, no way. (And that's where I do most of my work, upgrading and downgrading everything but the kernel when necessary with nary a hiccup, and no reboot-associated state loss. Yes, I know this setup is 'obsolete' now in the brave new Web 3.0 world where everyone uses horrible proprietary web services rather than anything like shared filesystems, but it meant I and some friends could band together and buy one big RAIDed box with ECCRAM that none of us could otherwise afford, and it means lower power costs than each of us owning a medium-big box.)

What's bizarre is that you reference nixos, which does most of this right (and which I am not associated with in any way, despite the coincidence of names: nixos *does* do some things wrong, including, last time I looked, paying no attention to the fact that most shared library upgrades do not break compatibility) -- and then you go on to propose a system which is as far as I can tell worse in every way in which it differs from nixos. Why?!

Day: GNOME OS

Posted Aug 8, 2012 20:05 UTC (Wed) by walters (subscriber, #7396) [Link]

So you're just wrong about the systemwide configuration bit; concretely, it will absolutely be possible to change say /etc/passwdqc.conf and have that apply to every root you boot into.

On the "live updates" part: Absolutely nothing precludes having a mechanism which attempts to apply "live" updates from the new root to the currently running system. In fact, one could trivally reproduce the semantics that dpkg/RPM provide by just doing a "rsync --delete /ostree/trees/new/ /ostree/trees/current/" underneath the bind mount.

But the point is that comes *afterwards*. Make operations safe by default, and optimize later. But remember - there's lots of evil race conditions that happen on "live" updates as package managers do today.

Also remember that I fully intend to allow having a hybrid OSTree+package model, where you have a base system (basically ostree+dependencies) that must be updated atomically, but everything else can be mutated at runtime, if you like.

Day: GNOME OS

Posted Aug 8, 2012 6:35 UTC (Wed) by drag (subscriber, #31333) [Link]

> what are the goals for GNOME?

It appears to be to make the software more usable and improve the ease writing and installing software.

> Is it building a Linux distribution?

Hopefully not, because Linux needs a new distribution like I need another hole in my head.

> Creating an OS for tablets and smartphones?

No. But having desktop that is also usable on a touch screen is a important priority for them. This is something that Linux distributions, in general, never had in the past. There existed lots of software and environments that were intended to make writing and using touch screen oriented software easier, but nothing in general to make Linux desktop usable using anything other then a keyboard and pointer device.

> Is it going to provide a low-level framework comparable to SELinux or seccomp?

Doesn't seem like it. They seem much happier working with "linux plumbing" type developers to improve and develop low-level Linux userland stuff like Systemd, udev, NetworkManager, and Pulseaudio to make Gnome better.

However they seem to be happy making software that uses low-level things better, like Boxes for Libvirt/KVM and panel items that work with NetworkManager or Pulseaudio...

> Is it going to create a new build system to compete with Koji, CDBS, or the Gentoo build system?

Gnome always had their own build system called jhbuild that would go out and download code from various repositories and build stuff. Other older large software projects had their own fetch and build systems too. Once projects reached a certain size or complexity they tend to develop tools to make downloading and building software easier for themselves. As with a number of languages and other frameworks... such as 'pip' for python (one of many for python) or cpan for perl.

Apparently they would like to improve it and create more formal set of APIs for developers to use.

Day: GNOME OS

Posted Aug 8, 2012 7:40 UTC (Wed) by liam (subscriber, #84133) [Link]

I really hope gnome doesn't try to extend jhbuild (though my experiences with it were not as bad as some). I find it hard to believe they haven't long since migrated to something like hudson/jenkins.
Why build your own widget if someone is giving away free widgets of the kind you want?

Day: GNOME OS

Posted Aug 8, 2012 8:18 UTC (Wed) by ovitters (subscriber, #27950) [Link]

We combined jhbuild and buildbot years ago: http://build.gnome.org/.

If you want to help, feel free. I'll re-activate gnome-os-list in a bit, just subscribe, etc. We also have a buildbridage list, but that is pretty dead.

Day: GNOME OS

Posted Aug 8, 2012 10:36 UTC (Wed) by Frej (subscriber, #4165) [Link]

Ever thought of reusing homebrew instead of homegrown jhbuild? It does solve the 'install software on top/next to" another distro. But in this case the base distro is OSX, however it should be quite portable.

My recollection of jhbuild was just pain, it might be better today :)

Day: GNOME OS

Posted Aug 8, 2012 8:38 UTC (Wed) by Pawlerson (guest, #74136) [Link]

It appears to be to make the software more usable and improve the ease writing and installing software.
There's something wrong here. If they want to make the software more usable then why they're turning it to be unusable?

Day: GNOME OS

Posted Aug 8, 2012 8:48 UTC (Wed) by drag (subscriber, #31333) [Link]

You are confused. I suggest trying to re-assessing your assumptions to make them match closer to reality.

Day: GNOME OS

Posted Aug 8, 2012 10:35 UTC (Wed) by jjs (guest, #10315) [Link]

I don't think he's confused. I loved GNOME1. Then GNOME2 came out, and I couldn't tweek it as much as I wanted, because it was determined that "I really didn't need to do that" and "it's too confusing." So I moved to WindowMaker and XFCE. Kept trying GNOME2, occasionally using GHOME2 apps. GNOME3 came out - and I'm really moving to KDE for apps (as well as WindowMaker, XFCE, LDXE, and Enlightenment).

GHOME3 is another step away from supporting users, IMHO.

Day: GNOME OS

Posted Aug 8, 2012 14:11 UTC (Wed) by drag (subscriber, #31333) [Link]

I loathed Gnome 1. I was very happy when I learned that I could run Enlightenment without it. I didn't touch Gnome again until 2.8 or so when it finally started becoming usable.

To each their own.

Day: GNOME OS

Posted Aug 9, 2012 16:16 UTC (Thu) by thebluesgnr (guest, #37963) [Link]

GNOME is not for you; that's fine. That's not the same as saying it's not "supporting the users". Keep in mind you're not the only user in the world. ;)

Day: GNOME OS

Posted Aug 8, 2012 16:29 UTC (Wed) by nevets (subscriber, #11875) [Link]

> No. But having desktop that is also usable on a touch screen is a important priority for them. This is something that Linux distributions, in general, never had in the past. There existed lots of software and environments that were intended to make writing and using touch screen oriented software easier, but nothing in general to make Linux desktop usable using anything other then a keyboard and pointer device.

I'm curious to why this is important?

By making a desktop environment that works well with touch-screens, they created one that works horrible with a mouse and keyboard. I don't know many desktops with touchscreens, except for kiosks and the like. The last thing I want to do is to mess up my monitor with fingerprints.

Day: GNOME OS

Posted Aug 8, 2012 17:22 UTC (Wed) by drag (subscriber, #31333) [Link]

> I'm curious to why this is important?

Things like tablets are reaching parity with desktops and laptops in terms of performance and capabilities. Ideally they are not going to be locked down as much as they traditionally have been.

Also there are now more and more ways to interact with computers.

> By making a desktop environment that works well with touch-screens, they created one that works horrible with a mouse and keyboard

Mousing leaves a little bit to be desired, but Gnome 3 a hell of a lot more keyboard friendly then Gnome 2 was. A exponential improvement, IMO.

If you prefer to have window lists, static desktop choosers, start menus
and the like to make mousing friendlier they can be taken care of with extensions easily enough, although I hope that Gnome folks will address some of the current mouse limitations.

> I don't know many desktops with touchscreens, except for kiosks and the like.

Koisk and point of sales are big ones. Despite Linux popularity in embedded devices the Linux environment proved too problematic for these sorts of things as POS seems to be predominately XP POS (a actual microsoft product)

> The last thing I want to do is to mess up my monitor with fingerprints.

In practice it doesn't seem to be a problem except that touchscreens are miserable on desktops and laptops anyways. Nobody wants that.

A nice way to try out Gnome 3 on a tablet-like struction would be on one of those Mimo USB+touchscreen monitors, if/when they get the GPU offload stuff sorted out.

Day: GNOME OS

Posted Aug 8, 2012 7:46 UTC (Wed) by epa (subscriber, #39769) [Link]

I understood the SDK partly as meaning they plan to stop breaking compatibility every couple of years. This blog post from Miguel in 2008 comes to mind: http://tirania.org/blog/archive/2008/Jul-15.html

Now this is a good intention, but you know what they say about those... It seems to be saying 'never mind all the past compatibility we have broken and the older code we are no longer msintaining - it will be different in future!' Which does not have a lot of credibility, since actions speak louder than words. It would be better to undo at least the more recent breakages (say, by continuing to actively support GTK2) rather than rush forward to yet another new rewrite cycle with the promise that this time things will be different. Who can say whether four years from now the developers will not have forgotten? Keeping compatibility is something you need to practise on a small scale from day to day, as the kernel developers do, not something you can simply declare to happen in the future while ignoring the present and recent past.

Day: GNOME OS

Posted Aug 8, 2012 9:31 UTC (Wed) by dgm (subscriber, #49227) [Link]

Thanks for the link to Miguel's blog. I think this is the first time I have agreed 100% with something de Icaza has said. There's a first time for everything, I guess.

Day: GNOME OS

Posted Aug 12, 2012 13:39 UTC (Sun) by khim (subscriber, #9252) [Link]

It would be better to undo at least the more recent breakages (say, by continuing to actively support GTK2) rather than rush forward to yet another new rewrite cycle with the promise that this time things will be different.

This is not always possible. GLibC is one of the most stable pieces of Linux stack - yet it was broken horribly in Libc5-to-Libc6 (AKA GLibC 2) transition.

The fact that incompatible GTK 3.0 was ever released is a shame because GTK2 itself was pretty stable, but when you want to create stable ABI then often it's better to throw away existing unstable ABI and create a new one from scratch because ABIs designed to be stable and ABIs designed to unstable and efficient are fundamentally different. If your ABI is supposed to be evolving then you only pass the information you actually need around because you can always add missing pieces later. If your ABI is supposed to be stable then you pass more data then you need today because you are not sure if it'll be needed later or not. And this is just the tip of the iceberg.

Day: GNOME OS

Posted Aug 14, 2012 2:05 UTC (Tue) by paulj (subscriber, #341) [Link]

The Linux libc5 to libc6 breakage was not GNU libc being unstable. libc5 was not GNU libc, GNU had nothing to do with its development. Libc5 - "Linux libc" - was a separate code-base (an old fork of a much earlier GNU libc, apparently).

Day: GNOME OS

Posted Aug 14, 2012 17:41 UTC (Tue) by khim (subscriber, #9252) [Link]

You nitpicking is correct - but pointless. Many former libc5 developers are GLibC 2.x developers today. And the fact that they decided to pick up the GLibC 2.0 to use it as Linux libc (instead of trying to stabilize libc5) proves my point: they broke compatibility at least four times in a short while when Linux libc was developed as a fork but then they decided that they want to stabilize ABI and they were able to do this with a switch to GLibC.

Stable ABI is less of a technical phenomenon and more of a social phenomenon: if you want to have stable ABI then you must plan for the stable ABI and if you don't plan for the stable ABI then usually ABI can not be safely frozen.

Good example are Linux kernel developers: they are often accuses in various vices because they don't keep internal Linux ABI stable and usually people say that this happens because these guys just don't know how to program in general and how to program stable ABI in particular but these critics often forget that these same guys are designing and supporting kernel<->userspace ABI which may be not perfect yet is quite stable.

If you want to change a library and stabilize it's ABI then often the only sensible way to do it is to break it's ABI "just one last time".

Prediction

Posted Aug 8, 2012 4:46 UTC (Wed) by bojan (subscriber, #14302) [Link]

Oregano OS fork available by Friday. ;-)

Day: GNOME OS

Posted Aug 8, 2012 15:01 UTC (Wed) by Zizzle (guest, #67739) [Link]

I think this blog post makes more sense as a strategy.

http://blog.monotonous.org/2012/08/07/gnome-workstation-os/

Flash and H.264 have show that content creation tools matter more than freeness to most people.

So why aren't we building good content creation tools?

Day: GNOME OS

Posted Aug 8, 2012 21:14 UTC (Wed) by cmccabe (guest, #60281) [Link]

I stopped reading after I saw that the linked post used "social" as a noun.

But yes, it would have made FAR more sense to perfect things like swfdec and gimp than to do GNOME3, if that's what you're getting at.

Day: GNOME OS

Posted Aug 8, 2012 23:30 UTC (Wed) by bojan (subscriber, #14302) [Link]

You should have read it. The article declares nothing short of victory with Gnome 3:

> Our strengths are pretty obvious too: In the last few years we successfully refreshed the desktop work flow and our entire framework. [..snip..] We created a distraction free environment that lets users get work done.

There is that "philosophical" nonsense again with "distraction free environment". And that is the major downfall of Gnome - some misguided notion that users care about "philosophy" of their desktop. With pearls of wisdom like that, combined with:

> "Displaying multiple windows at the same time means that screen space isn't used efficiently [..snip..]"

by Allan Day (http://afaikblog.wordpress.com/2012/02/10/a-new-approach-...), what can one _really_ expect?

I have four users at home (including myself) and we all work in entirely _different_ ways on our computers. The "one philosophy fits all" approach by Gnome isn't going to cut it - that is a given. Especially when one considers that the world has a few more than four users.

But, let me finish on a positive note. Problems with Gnome 3 can be fixed relatively easily. The Cinnamon effort is the proof. If only Gnome developers acknowledged that.

Day: GNOME OS

Posted Aug 9, 2012 11:28 UTC (Thu) by Rehdon (guest, #45440) [Link]

Alas, I don't think that will happen any time soon. I'll keep using Cinnamon (1.6 should be out soon with nice new features) in the meanwhile ;)

Rehdon

Day: GNOME OS

Posted Aug 9, 2012 16:12 UTC (Thu) by thebluesgnr (guest, #37963) [Link]

I don't think the GNOME developers would have spent a significant amount of resources on http://extensions.gnome.org if they didn't believe people can customize the software to their experience. In fact, GNOME 3 is the most extensible and customizable version of GNOME yet, so I don't see where your complaint is coming from.

Of course, some music players ask you if you prefer xine, gstreamer or mplayer when you boot them up... or MySQL vs PostgreSQL vs SQLite... GNOME will never target people that want that kind of control, and there's nothing wrong with that.

Day: GNOME OS

Posted Aug 9, 2012 21:35 UTC (Thu) by bojan (subscriber, #14302) [Link]

Think about it - even moving an icon requires someone to write code. Ridiculous. No other UI has that kind of limitation.

Day: GNOME OS

Posted Aug 9, 2012 21:58 UTC (Thu) by bojan (subscriber, #14302) [Link]

One more detail. At the bottom of this page http://intgat.tigress.co.uk/rmy/extensions/index.html, you will find a piece of text that is rather instructive when it comes to extensions:

> During development and testing I have only the Frippery extensions installed. There will be conflicts between extensions and it's impossible to test all combinations. I do try to resolve conflicts that are brought to my attention but all I can guarantee is that the Frippery extensions are compatible with one another.

Extensions are an afterthought, created because people could not do with Gnome 3 what they expected from it (and now extension developers are paying the price). The basic ability to customise should have been part of the system from day one. In fact, if Gnome 3 is an upgrade from Gnome 2, then lack of being able to customise is a regression.

Day: GNOME OS

Posted Aug 10, 2012 0:50 UTC (Fri) by thebluesgnr (guest, #37963) [Link]

Ah, I see; they purposefully create a new piece of technology from scratch in Javascript due to its extensibility; they make extensions work day 1; they invest a significant amount of time on the web infrastructure required to make extensions.gnome.org work; they review hundreds of extensions posted by users in their free time. And instead of getting thanks, they get accused of doing all that work just so they can pry and torture their poor users from the beloved taskbar and windows 95-like application menu. I mean, imagine if two extensions conflict with each other! The horror!

They're some devious creatures indeed, I'm not buying software from them anymore.

Day: GNOME OS

Posted Aug 10, 2012 3:10 UTC (Fri) by slashdot (guest, #22014) [Link]

Well, extensions are good.

But obviously, having extensions doesn't excuse you from providing a configurable UI (esp. since all serious applications have supported toolbar customization since around 15 years ago at least).

Not only writing code is much more time consuming than configuring, but options never conflict, while there is no way to make arbitrary extensions not conflict.

For example, if you look at Firefox, you can:
1. Right click on toolbar, click Customize, and rearrange everything (buttons, URL bar, search bar, etc.) arbitrarily
2. Use a preferences dialog with quite a bit of stuff
3. Type "about:config" and configure anything with a list interface
4. Write and install extensions

This is what any serious software must provide, and that's obvious even to a beginning user.

Day: GNOME OS

Posted Aug 12, 2012 13:57 UTC (Sun) by khim (subscriber, #9252) [Link]

Not only writing code is much more time consuming than configuring, but options never conflict, while there is no way to make arbitrary extensions not conflict.

Sorry, but this post contains so much nonsense I don't even know where to start. Probably from the beginning.

  1. Not only writing code is much more time consuming than configuring — nope. You can only configure something if someone else coded that something first and provided options to configure it, too!
  2. Options never conflict — have you done any software development at all? Options conflict all the time — and these conflicts must be resolved by program developers, but extension writers. And their number is limited. That's why software evolves from the options to extensions.
  3. Think about it - even moving an icon requires someone to write code. Ridiculous. No other UI has that kind of limitation. — Hmm… I know, I'm dumb (noone contradicted this statement yet so it's probably just me). Can you point me to step-by-step instruction which explains how to move icons in one of three products:
    1. iOS home screen
    2. MS Office 2010 ribbon toolbar
    3. Android's list of applications
    When you'll present such howtos you'll have a point.

Day: GNOME OS

Posted Aug 14, 2012 6:08 UTC (Tue) by bojan (subscriber, #14302) [Link]

> Can you point me to step-by-step instruction which explains how to move icons in one of three products:

> iOS home screen
> MS Office 2010 ribbon toolbar
> Android's list of applications

I do not use Office 2010, so I cannot tell you that (but Google points to many answers - do yourself a favour - use it).

I can tell you about iOS home screen. You hold one of the icons until they all start shaking. Then you rearrange them using your finger, by dragging and dropping.

I can also tell you about Android (well Galaxy S2 anyway). You tap options, then edit. Then you just drag and drop with you finger.

I have no idea what the point of your question was.

Day: GNOME OS

Posted Aug 14, 2012 6:13 UTC (Tue) by bojan (subscriber, #14302) [Link]

> You can only configure something if someone else coded that something first and provided options to configure it, too!

Which is the point of our complaint. Gnome 3 developers did not code a generic way to do the most trivial of things for a GUI - rearrange elements on the screen. Duh!

Instead, for someone to move an icon by one position on the grid, you have to create or download code. But, if you want to move it by two, you may be out of luck. Totally and utterly ridiculous, of course.

Day: GNOME OS

Posted Aug 14, 2012 10:28 UTC (Tue) by slashdot (guest, #22014) [Link]

> You can only configure something if someone else coded that something first and provided options to configure it, too!

Yeah, except that's done once rather than every time a user needs to do something slightly different.

> Options conflict all the time — and these conflicts must be resolved by program developers,

Of course.

That's the whole fucking job of the program developers, making sure their software works, in all configurations!

Again, it's DONE ONCE and TESTED.

> And their number is limited. That's why software evolves from the options to extensions.

For things that do not conflict with other functionality.

> Can you point me to step-by-step instruction which explains how to move icons in one of three products

Microsoft Office 2010 ribbon toolbar:
1. Right click on ribbon
2. Click on "Customize the ribbon..." in the popup menu
3. Use the two buttons on the right with the up and down arrow to move toolbar item groups left/right, hide them, move to different panes
4. Use the "Add >>" and "<< Remove" to add/remove stuff from the toolbar
5. Export your toolbar configuration to a file using "Import/Export"

As you can see, real applications with actual market share are not toys and can be configured.

Day: GNOME OS

Posted Aug 10, 2012 6:38 UTC (Fri) by bojan (subscriber, #14302) [Link]

> Ah, I see; they purposefully create a new piece of technology from scratch in Javascript due to its extensibility; they make extensions work day 1; they invest a significant amount of time on the web infrastructure required to make extensions.gnome.org work; they review hundreds of extensions posted by users in their free time.

And all to remove accessibility icon, for instance. Or to not have to press Alt to shut the system down. Ridiculous. Objectively, forcing someone to write Javascript to move/remove an icon or set basic options is a regression when compared to Gnome 2. Maybe even Windows 3.1?

> And instead of getting thanks, they get accused of doing all that work just so they can pry and torture their poor users from the beloved taskbar and windows 95-like application menu.

Only because the newfangled "overview" requires significantly more GUI/mouse actions to do things, provides no visibility of the desktop or minimised/obscured windows and attacks users with visual elements that they never wanted to use. These are objective, measurable regressions.

> I mean, imagine if two extensions conflict with each other! The horror!

Yeah, the horror indeed. The combinatorial explosion of possible conflicts is mind boggling. And all to do what? Something that all other desktops can do already, without writing any code?

Look, I understand why the home screen is removed from view when I start an app on my Galaxy S2. There isn't enough space to have the home screen and the app on that device's screen at the same time. But to remove my windows from view for me to start an app on my 1600 x 900 laptop screen? Or someone's 27" 2560 x 1400 screen? What's that about?

Day: GNOME OS

Posted Aug 10, 2012 11:22 UTC (Fri) by paulj (subscriber, #341) [Link]

All that extensibility work is great for someone, I'm sure. But I just wanted to be able to drag menu entries onto my task-bar, like I used to be able to.


Copyright © 2012, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds