Fedora 19 released
| From: | Robyn Bergeron <rbergero-AT-redhat.com> | |
| To: | announce-AT-lists.fedoraproject.org, test-announce-AT-lists.fedoraproject.org, devel-announce <devel-announce-AT-lists.fedoraproject.org> | |
| Subject: | Announcing the release of Fedora 19! | |
| Date: | Tue, 2 Jul 2013 10:01:29 -0400 (EDT) | |
| Message-ID: | <514159827.106840037.1372773689784.JavaMail.root@redhat.com> | |
| Archive‑link: | Article |
The Fedora Project is delighted to announce the release of Fedora 19 ("Schrödinger's Cat"). Open
the box and take a look for yourself!
Fedora is a leading-edge, free and open source operating system that continues to deliver
innovative features to many users, with a new release about every six months.
Download it now:
http://fedoraproject.org/get-fedora
Detailed information about this release can be seen in the release notes:
http://docs.fedoraproject.org/en-US/Fedora/19/html/Releas...
** What's New in Fedora 19? **
The Fedora Project takes great pride in being able to show off features for all types of use cases,
including traditional desktop users, systems administration, development, the cloud, and many more.
But a few new features are guaranteed to be seen by nearly anyone installing Fedora and are
improvements that deserve to be called out on their own.
A complete list with details of each new feature is available here:
http://fedoraproject.org/wiki/Releases/19/FeatureList
== Make new things ==
Would you like to play? Whether you're a developer, maker, or just starting to learn about open
source development, we have what you need to bring your ideas to reality. Here's a peek at some of
our new tools:
* Developer's Assistant is a tool for new developers that helps you to get started on a code
project by offering templates, samples, and toolchains for a variety of languages. And when you're
finished, you can publish directly to GitHub!
* 3D modelling and printing are supported with OpenSCAD, Skeinforge, SFACT, Printrun, RepetierHost,
and other tool options. Get printing without having to download binary blobs or run Python code
from git.
* OpenShift Origin makes it easy for you to build your own Platform-as-a-Service (PaaS)
infrastructure, allowing you to enable others to easily develop and deploy software.
* node.js is a popular Javascript-based platform for those building scalable network applications
or real-time apps across distributed devices.
* Ruby 2.0.0 moves into Fedora but keeps source-level backwards compatibility with your Ruby 1.9.3
software. We're also giving you a custom Ruby loader to use to easily switch interpreters.
* MariaDB offers a truly open MySQL implementation and is now the default MySQL option in Fedora.
== Deploy, Monitor, and Manage ==
You don't have to work so hard when your machines are doing it for you. Regardless of how many you
have, Fedora 19 helps you boot-manage your systems and gives you the tools you need for diagnosis,
monitoring, and logging.
* systemd Resource Control is one of many systemd enhancements in this release. It lets you modify
your service settings without a reboot by dynamically querying and modifying resource control
parameters at runtime.
* Kerberos administrators no longer need their clients to sync their clocks or to have reverse DNS
records carefully setup for services. Fedora 19 also includes Kerberos-enabled, LDAP replicated,
two-factor authentication for FreeIPA.
* Checkpoint & Restore lets you checkpoint and restore a process. It is useful for issues like
process failure or moving a process to another machine for maintenance or load balancing.
* OpenLMI is a common infrastructure for the management of Linux systems that makes remote
management of machines much simpler.
== Desktop Environments and Spins ==
GNOME 3.8 brings new applications such as clock and improvements to the desktop including privacy
and sharing settings, ordered search, frequent applications overview, and additionally provides the
ability to enable GNOME Classic ("classic mode") for a user experience similar to GNOME 2 built out
of a collection of GNOME Shell extensions. Refer to https://help.gnome.org/misc/release-notes/3.8/
for more details.
KDE Plasma Workspaces 4.10: A modern, stable desktop environment, KDE Plasma Workspaces 4.10
includes new features for printing and screenlocking, better indexing of files, and improved
accessibility features. Refer to http://www.kde.org/announcements/4.10/ for more details.
MATE Desktop 1.6 introduces a large number of improvements to this traditional, GNOME 2-like
desktop interface. Refer to http://mate-desktop.org/2013/04/02/mate-1-6-released/ for more
details.
== Spins ==
Spins are alternate versions of Fedora. In addition to various desktop environments for Fedora,
spins are also available as tailored environments for various types of users via hand-picked
application sets or customizations.
Interest-specific Spins include the Design Suite Spin, the Robotics Spin, and the Security Spin,
among others. Other available desktop environments, in addition to the GNOME 3.8 desktop which is
shipped in the default version of Fedora 19, as well as those highlighted above, Xfce, Sugar on a
Stick, and LXDE.
To see all of the Official Fedora 19 Release Spins, visit:
http://spins.fedoraproject.org
Nightly composes of alternate Spins are available here:
http://dl.fedoraproject.org/pub/alt/nightly-composes
*** Downloads, upgrades, documentation, and common bugs ***
Start by downloading Fedora 19:
http://get.fedoraproject.org/
If you are upgrading from a previous release of Fedora, refer to:
http://fedoraproject.org/wiki/Upgrading
Fedora now includes FedUp in order to enable an easy upgrade to Fedora 19.
*** Documentation ***
Read the full release notes for Fedora 19, guides for several languages, and learn about known bugs
and how to report new ones:
http://docs.fedoraproject.org/
Because of the number of changes to the installer, we particularly suggest taking a peek at the
Installation Guide:
http://docs.fedoraproject.org/en-US/Fedora/19/html/Instal...
Fedora 19 common bugs are documented at:
http://fedoraproject.org/wiki/Common_F19_bugs
This page includes information on several known bugs in the installer, so we recommend reading it
before installing Fedora 19.
*** Contributing ***
We can't build Fedora inside a box. We need your help! Bug reports are especially helpful--if you
encounter any issues, please report them!
Fedora is a fantastic, friendly community, and we have many ways in which you can contribute,
including documentation, marketing, design, QA, and development.
To learn how to help us, visit:
http://join.fedoraproject.org/
*** Fedora 20 ***
Fedora 20 has been in active development for several months already. We plan to release it in
November 2013, though the final schedule is part of the planning process and subject to change:
https://fedoraproject.org/wiki/Releases/20/Schedule
*** Contact information ***
If you are a journalist or reporter, you can find additional information here:
https://fedoraproject.org/wiki/Press
Enjoy!
-Robyn Bergeron
--
announce mailing list
announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/announce
Posted Jul 2, 2013 14:30 UTC (Tue)
by proski (subscriber, #104)
[Link] (2 responses)
One the positive side, gnome-control-center works in LXDE now. In particular, the sound settings work. The LXDE's native sound control used to be inadequate, it's better now.
Posted Jul 2, 2013 18:45 UTC (Tue)
by mathstuf (subscriber, #69389)
[Link] (1 responses)
Posted Jul 3, 2013 15:55 UTC (Wed)
by proski (subscriber, #104)
[Link]
Posted Jul 2, 2013 15:45 UTC (Tue)
by ken (subscriber, #625)
[Link] (8 responses)
Reason for this is that installation program split the disk in two with one partition used for swap. Why create a swap ? especially when the result is an unusable system.
I have not created a swap partition on any of my systems since swap files support was added and I would really like to see dynamically sized swapfile also since swap is almost never used anyway and making swapping a bit slower is not going to be noticed but it would avoid having to preallocate the swapfile.
Posted Jul 2, 2013 16:00 UTC (Tue)
by etienne (guest, #25256)
[Link]
Posted Jul 2, 2013 16:23 UTC (Tue)
by dowdle (subscriber, #659)
[Link] (6 responses)
Posted Jul 2, 2013 16:58 UTC (Tue)
by ken (subscriber, #625)
[Link] (5 responses)
I really wish they had put effort into making gnome-disks usable for installation instead of inventing yet another gui for handling disks. I'm sure someone thought that it was easier doing a new one but it's not easier for the user.
Posted Jul 2, 2013 17:41 UTC (Tue)
by luya (subscriber, #50741)
[Link]
Storage partition was always a complex matter. Your case is different which is why "custom partition" exists.
Posted Jul 2, 2013 17:49 UTC (Tue)
by dowdle (subscriber, #659)
[Link] (3 responses)
If you want to use gnome-disk prior to doing the install, it is on the GNOME media so go for it. I believe every spin has fdisk so anyone who wants to use that from the command line can. I make my own Fedora remix and include gparted and sometimes use gparted before I do an install.
I agree with you that the installer's partitioning functionality is more clunky than some other programs but I have used the installer's partitioning functionality in Fedora 18 and 19 (I followed the pre-releases and did a lot of installs) and it works quite well. It isn't the broken mess that some claim it to be. You should be able to do most everything you want to do with the custom partitioning option... but yes, if you are very new to the installer you are going to have to read the screen.
Posted Jul 3, 2013 14:26 UTC (Wed)
by drag (guest, #31333)
[Link] (2 responses)
The big problem is that the world has moved on and BIOSes no longer have the capability of booting from modern hard drives without some effort on the part of the end user and/or installer.
We have machines that are BIOS-only, have a EFI stub that boots a BIOS analog, and pure EFI. We have 'regulare' 2TB and smaller drives that can be partitioned successfully with just a MBR style partitioning scheme and we have 2TB and larger drives that require GPT. We also have 2TB and smaller drives with 'regular' 512byte sectors, 2TB and larger drives with large sectors, and then SSD drives that are a bewildering array of different sized write blocks, erase blocks, and emulation to support 512byte blocks with a performance penalty.
Then on top of that we require no less then two versions of grub in order to boot either a EFI or BIOS machine.. when it's really often not entirely clear if a machine is a EFI or BIOS machine.
This may sound like a PITA, but we have lots of choice! And lots of choice and billions of variables is the only way we ever get progress, right? (end sarcasm)
The 'most correct' way of partitioning a drive nowadays from what I can tell is to have at least 4 partitions and to have it using GPT partitions. Although obviously other partition schemes will work.
1. You need a 'BIOS Boot Partition'. This a very small, just a meg or two at most, partition that is required for BIOS compatibility. It actually works quite well and I dare say that when you are moving drives around I think it is actually more reliable then trying to just use a tradition grub install. There is a partition flag you set to make it into a 'bios boot partition'.
2. You need a 'Boot partition', formated ext4 to have all the kernel/grub stuff.
3. You need a swap partition. On modern machines with lots of RAM I usually make it just 8GB.
4. You need a partition (or more) for 'everything else'. Hopefully in the near future we can just set it to BTRFS and not have to give a crap anymore and go back to something that more closely resembles the way BSD folks run things.
I fully applaud the Fedora 'confusingly simple' interface. The chances of users actually ending up with a effective partitioning scheme when they are given a chance to meddle with things is vanishingly small. It definitely needs work still, but it's a lot better then F18.
A couple notes:
Fedora now users TMPFS for /tmp. So you want plenty of swap to get any big files out of memory if you need to.
Suspend-to-disk seems quaintly antiquated nowadays. The time that it takes to write out 8-32GB of RAM to disk is excessive to say the least. Maybe as disks catch up to speed with the rest of the system then it will have a purpose again.
Posted Jul 3, 2013 15:35 UTC (Wed)
by AdamW (subscriber, #48457)
[Link]
Remember, UEFI machines can boot in BIOS compatibility mode. And when you're doing a UEFI install to gpt you don't need a BIOS boot partition, you need an EFI system partition. Which may be required to be marked bootable or may be required to absolutely *not* be marked bootable, depending on circumstances. It certainly has to be of the correct filesystem, type, and mounted in the right place. You can apparently do native UEFI installs to msdos-labelled disks, which makes no goddamn sense but that of *course* does not stop some manufacturers from doing it (we only figured this out in the last week of f19 release, so that case is busted in f19, unfortunately).
You don't actually need a separate /boot or swap partition, but it's a good idea to have them.
Posted Jul 3, 2013 22:49 UTC (Wed)
by Ed_L. (guest, #24287)
[Link]
I like your partitioning scheme. One might also mention that grub2 requires a larger embedding area or BIOS boot partition than grub1 when booting from an mdraid. 63 sectors -- 31kb -- is not sufficient. Make it at least a MB, like drag said.
Posted Jul 2, 2013 18:35 UTC (Tue)
by hadrons123 (guest, #72126)
[Link] (59 responses)
I don't understand how the QA doesn't think it as critical. https://bugzilla.redhat.com/show_bug.cgi?id=886029.
depressingly Poor QA for the all the RH money spent on the quality.
Later that day I tried Gentoo stable and I am happy with Gnome2.
Posted Jul 2, 2013 18:42 UTC (Tue)
by rahulsundaram (subscriber, #21946)
[Link] (57 responses)
"Sometimes (the bug is due to a race condition and hence unpredictable), on boot of the Fedora 19 MATE live image or first login with a user account to the MATE desktop, several useless windows labelled x-caja-desktop will open up on the desktop.
The bug has no further consequences and it is quite safe to simply close the windows and continue using the system. The MATE maintainer is currently working to resolve this issue with updated packages."
Posted Jul 2, 2013 19:02 UTC (Tue)
by hadrons123 (guest, #72126)
[Link] (56 responses)
Its giving poor rapport about the Mate-spin considering its the first time we are seeing a Fedora mate spin.
Ideally if you have cared about the users, QA should have waited until someone fixed the issue and released the CD when its ready.
Its not like an app from peanut gallery which is not critical. Its the **file manager** taking down the system and it should have been a blocker.
I am 100% sure Dan would fix this in short while. At least when this is fixed Fedora should release a new LiveCD for the benefit of the users.
Posted Jul 2, 2013 19:16 UTC (Tue)
by rahulsundaram (subscriber, #21946)
[Link] (4 responses)
Posted Jul 3, 2013 1:10 UTC (Wed)
by hadrons123 (guest, #72126)
[Link] (3 responses)
I can do it, dan can do it. Remaining 95% of the world can't do it. Why doesn't fedora update the official images for the rest of the world?
Posted Jul 3, 2013 2:05 UTC (Wed)
by brunowolff (guest, #71160)
[Link] (2 responses)
Posted Jul 3, 2013 2:27 UTC (Wed)
by hadrons123 (guest, #72126)
[Link] (1 responses)
Posted Jul 3, 2013 2:40 UTC (Wed)
by rahulsundaram (subscriber, #21946)
[Link]
Posted Jul 2, 2013 20:21 UTC (Tue)
by brunowolff (guest, #71160)
[Link]
Posted Jul 3, 2013 5:12 UTC (Wed)
by AdamW (subscriber, #48457)
[Link] (49 responses)
Very simply, because we have to draw a line somewhere. You cannot release a bug-free operating system, it is an impossible task.
One of the lines we draw is that only issues in KDE and GNOME are release-blocking. We can't practically speaking guarantee that every desktop we ship a live image for - KDE, GNOME, Xfce, LXDE, Sugar, MATE - will be perfect: our timeframes are too short and resources too scarce.
Not to throw Dan under any buses, I love the guy, but please note he and upstream have been trying to fix this issue for something like three months now. It is clearly not an easy fix. What do you want us to do? Delay the entire Fedora 19 release indefinitely (since we clearly have no reliable timeframe for a fix) due to a superficial bug in a single fairly new desktop spin?
We cannot, practically speaking, release one image significantly later than all the others with a new change; it throws the whole release process out of whack, since the release repositories are meant to be *frozen*.
The issue can be fixed for installed systems with an update, in any case.
Posted Jul 3, 2013 7:05 UTC (Wed)
by bojan (subscriber, #14302)
[Link] (44 responses)
Imagine a poor third part developer that wants to create a "Linux" desktop app. Which desktop to target? Which distro to target?
We really did shoot ourselves in the foot in the Linux desktop world, didn't we?
Posted Jul 3, 2013 7:24 UTC (Wed)
by halla (subscriber, #14185)
[Link] (36 responses)
For me as an app developer, life really is getting worse and worse. Unity on Ubuntu is bringing me a host of bug reports about missing menubars and things like that. Cinnamon on Mint crashes Krita with X11 errors, for some people. Gnome3 does something weird that causes Krita to become too big for the screen, so I had to hardcode fixes for that.
Not that Windows is any better, with weird bugs happening on XP, other weird bugs on Win8. Win7 seems fine, fortunately Vista seems not to be used anymore.
Posted Jul 3, 2013 8:38 UTC (Wed)
by ovitters (guest, #27950)
[Link] (34 responses)
Posted Jul 3, 2013 11:08 UTC (Wed)
by halla (subscriber, #14185)
[Link] (33 responses)
You find that a poor comment and an attack on people? If it's my opinion that people are responsible for something, I won't hesitate to say so, just because you think that's a personal attack. I also think that my examples of desktop fragmentation giving problems for application developers are pretty darn illuminating -- you find that a poor comment, too?
I find the trend to put down people with trendily-worded little nothings like "Trend to attack people on LWN and poor comments is sad" pretty sad myself.
Posted Jul 3, 2013 13:11 UTC (Wed)
by ovitters (guest, #27950)
[Link] (2 responses)
You complain that I object to your meaningless comment about Miguel, while you started this behaviour. If you want a good discussion, I can have it. But by just stating Miguel is the leading cause of fragmentation, that's just meaningless bullshit.
Also first claiming something then using that claim to back up that he's responsible: what kind of way of argument are you making? Don't you see that your logic is MIA?
Posted Jul 3, 2013 13:58 UTC (Wed)
by halla (subscriber, #14185)
[Link]
Apparently my opinion is making you so angry that feel you have to resort to being rude, twice in a row, but all the same, that doesn't change anything. You lack the authority to make me accept your opinion merely because you shout at me.
Miguel was the guy who left KDE to start Gnome, which means he is the guy who started the fragment the Linux Desktop. He is also the guy who claimed the Linux desktop was a failure because it's so fragmented.
You're free to disagree, but, frankly, I am not interested in another insult.
Posted Jul 3, 2013 15:00 UTC (Wed)
by maxiaojun (guest, #91482)
[Link]
Posted Jul 4, 2013 4:10 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (29 responses)
Sorry, but blame is squarely on the choice of Qt for KDE.
Posted Jul 4, 2013 15:06 UTC (Thu)
by anselm (subscriber, #2796)
[Link] (28 responses)
By the time the first official release of GNOME came out, Qt was already under a licensing scheme that ensured that it would continue to be available even if Troll Tech folded, was acquired, …. Licensing issues with Qt probably played a part in the decision to start GNOME – especially if one listens to the »official story« –, but NIH and »C++ hate« were also important contributing factors at the time.
If Qt licensing had really been the only problem with KDE, it would probably have been a lot easier to come up with a free reimplementation of Qt than to develop a complete desktop environment (including a toolkit – Gtk was nowhere near adequate at the time and needed major work) from scratch. On the other hand it would have been much less fun, and we know that, at the end of the day, fun for developers is what desktop environment development is all about.
Posted Jul 4, 2013 17:27 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (27 responses)
GTK, on the other hand, was provided under a nice friendly LGPL license.
Posted Jul 4, 2013 19:17 UTC (Thu)
by anselm (subscriber, #2796)
[Link] (26 responses)
According to the TrollTech web site (courtesy of the Wayback Machine), in 2000 a commercial Qt license was something like $1500 per year for a single developer, with discounts for multiple licenses (e.g., 30% for 7-9 developers). This included support and upgrades.
Considering what the cost of actually paying the developer would be for a year, that doesn't sound prohibitively expensive.
Posted Jul 4, 2013 20:06 UTC (Thu)
by rahulsundaram (subscriber, #21946)
[Link] (25 responses)
Posted Jul 4, 2013 20:33 UTC (Thu)
by anselm (subscriber, #2796)
[Link] (24 responses)
Which is obviously the reason why so many ISVs from »outside the US and some of Europe« have opted to base their proprietary applications on GNOME and Gtk instead. After all, the market is completely flooded with those …
Posted Jul 4, 2013 23:19 UTC (Thu)
by rahulsundaram (subscriber, #21946)
[Link] (20 responses)
Posted Jul 4, 2013 23:51 UTC (Thu)
by anselm (subscriber, #2796)
[Link] (19 responses)
It was Cyberax who claimed that ISVs found the commercial Qt license too expensive, and I was replying to that. I have no opinion regarding custom in-house applications, which are obviously under different constraints than software for external commercial distribution.
Anyway, my main point was that GNOME was started not exclusively because of KDE's licensing issues with Qt but also because of NIH and dislike of C++ on the part of the early GNOME developers. If Qt's licensing had been the only problem, it would clearly have been less work at the time to come up with a freely-licensed Qt clone to support KDE than to write most of a new X11 toolkit and a complete new desktop environment from scratch, and that would not have led to the same degree of fragmentation that we see now.
The fact that GNOME co-founder Miguel de Icaza later went on to develop Mono tells us that he doesn't seem to have a problem in principle with trying to clone huge pieces of very proprietary software such as .NET. Compared to the Microsoft stuff, Qt in the late 1990s was positively liberally licensed. Also, once a hypothetical free Qt clone had been finished to the degree that KDE ran on it, the KDE community could simply have abandoned the original Qt, thereby removing the necessity to track Qt forever the way Miguel de Icaza gets to track .NET.
Posted Jul 5, 2013 1:16 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (18 responses)
>Also, once a hypothetical free Qt clone had been finished to the degree that KDE ran on it, the KDE community could simply have abandoned the original Qt, thereby removing the necessity to track Qt forever the way Miguel de Icaza gets to track .NET.
Also, you might note that Mono right now is actually used on more machines than the total amount of classic Linux desktops. Mostly because it is THE ONLY real language and framework that can be used to create software for ALL of the major mobile devices.
Posted Jul 5, 2013 6:57 UTC (Fri)
by anselm (subscriber, #2796)
[Link] (17 responses)
So you say. I suppose that if one has no legal qualms about cloning .NET, what would keep one from cloning Qt? After all, Microsoft probably has more lawyers in the East Podunk, North Dakota, branch office than Trolltech ever had employees in the whole company.
And what does that have to do with anything? Presumably if Miguel de Icaza had devoted the same amount of energy to cloning Qt that he later put into cloning .NET all those machines might now be running his free Qt clone.
Posted Jul 5, 2013 7:03 UTC (Fri)
by mjg59 (subscriber, #23239)
[Link] (1 responses)
Based on personal experience: it's less difficult to write something with equivalent functionality than it is to write a re-implementation of something with a specified API.
Posted Jul 5, 2013 9:17 UTC (Fri)
by anselm (subscriber, #2796)
[Link]
Probably. After all, everyone knows that a college student would never be able to come up with something really big and complicated – like, say, an industry-strength Unix-like operating system kernel.
Posted Jul 5, 2013 7:04 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (14 responses)
Any realistic API-compatible clone of QT would be deemed a derived work because of the overwhelming number of literal copying that'll be required.
> And what does that have to do with anything? Presumably if Miguel de Icaza had devoted the same amount of energy to cloning Qt that he later put into cloning .NET all those machines might now be running his free Qt clone.
Posted Jul 5, 2013 7:31 UTC (Fri)
by anselm (subscriber, #2796)
[Link] (13 responses)
If there is stuff that you need to copy literally because it is the only way to do something then that stuff is probably not eligible for copyright in the first place. Given that copyright is supposed to protect the output of the creative process, generally a work needs to be creative in order to be copyrightable, and if there is only one possible way of writing something down then coming up with that way is not especially creative.
Posted Jul 5, 2013 7:53 UTC (Fri)
by dark (guest, #8483)
[Link] (12 responses)
Posted Jul 5, 2013 9:13 UTC (Fri)
by anselm (subscriber, #2796)
[Link] (11 responses)
This is what clean-room techniques are for. You have someone write a spec and/or tests and have somebody else, who hasn't seen the original (Qt or whatever) source, write the actual implementation to suit the spec and tests.
You obviously can't copy something that you have never seen, and anyway your own implementation will probably differ enough in detail to no longer look like an outright copy of the original to begin with.
It is probably worth noting that at the time we're talking about (late 1990s), Qt used to be considerably smaller and simpler than it is now.
Posted Jul 5, 2013 18:14 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (10 responses)
And anyway, you have now moved on from stuff that a small company or a collection of individuals can do to the stuff that requires a large company with a legal department.
Now think about it, suppose that I spent $100^500 to clone QT - what do I achieve?
Posted Jul 5, 2013 21:03 UTC (Fri)
by anselm (subscriber, #2796)
[Link] (9 responses)
Nobody needs to clone Qt now. For one, Qt is now available under a reasonable selection of licences, and secondly, Qt is by now uncomfortably large and complicated.
Cloning Qt instead of implementing GNOME and most of Gtk from scratch would have been a more reasonable proposition 15 years ago when Qt was a much smaller piece of software. We might have avoided the desktop environment fragmentation that plagues us now if we could have standardised on KDE at a fairly early stage instead of coming up with a competing desktop environment.
On the other hand, chances are that even if Qt had been available under the LGPL from the beginning, the GNOME people would still have started GNOME just to be contrary. GNOME was initially as much about NIH and not wanting to use C++ as it was about Qt licensing.
Posted Jul 5, 2013 21:09 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (8 responses)
What do you do? Spend millions to clone a crappy UI toolkit with a guaranteed lawsuit afterwards? And what for, just to appease a bunch of developers of a marginal desktop environment (KDE)?
Nope, GTK creation was an entirely logical step at that time. Dislike of C++ might have played a role, but it wasn't decisive.
Of course, NOW we have QT under a reasonable license and it's much better than GTK. But we're talking about ancient history.
Posted Jul 5, 2013 21:25 UTC (Fri)
by anselm (subscriber, #2796)
[Link] (7 responses)
If it had been up to me personally, I would have put the same effort that the GNOME people put into making Gtk usable (it was really bad at the time) into Tk instead (which was freely available and a lot farther along than Gtk). But of course the GNOME people didn't like that idea, either – NIH, remember –, so they basically had to roll their own no matter what. A bit like what the Canonical folks are doing today.
Posted Jul 5, 2013 21:39 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (6 responses)
It had its own problems and idiosyncrasies: it was not themeable, it had poor cross-platform support, no support for TrueType fonts and so on. Oh, and it also was butt-ugly.
"Approaching user interface design with a programmer's mindset can only end in pain, tragedy, and Tk." (c) David Vallner.
Posted Jul 5, 2013 23:27 UTC (Fri)
by anselm (subscriber, #2796)
[Link] (5 responses)
Tk has been themable for a number of years now; there is no reason to believe that with appropriate effort that could have been built in earlier. As far as cross-platform support goes, you are misinformed; in the late 1990s Tk ran on Windows and the Mac as well as on X11 (including unusual X11 platforms like VMS), with native-looking widgets. In the late 1990s, TrueType font support was basically up to the X server, so if your X server supported them then Tk would too. (Now that we have XRENDER Tk of course supports that.) »Ugly« is in the eye of the beholder; Tk was originally built to look like Motif, which in the early 1990s was the obvious thing to emulate. In the meantime tastes have changed, and with Tk's theme support there is no reason why a Tk GUI should look any different than a Qt or Gtk GUI.
Tk also had some good things going for it in the late 1990s, such as very flexible geometry management, reasonable UTF-8 support (which at the time no other popular toolkit bothered with), or the canvas and text widgets which were really quite useful. It always seemed silly to me that somebody would spend vast amounts of effort to make Gtk into something that anyone except the GIMP developers would actually want to use; the same amount of work put into Tk would easily have taken care of all the things that people like bashing Tk for and then some. But then of course there is no accounting for taste, and »NIH« is a very powerful motivator.
Posted Jul 6, 2013 1:03 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (4 responses)
Sorry, you can't have it both ways. Either GTK was a logical step to create a free UI toolkit, or KDE caused huge fragmentation by choosing a proprietary UI toolkit instead of working with free UI toolkit developers.
Posted Jul 6, 2013 12:27 UTC (Sat)
by anselm (subscriber, #2796)
[Link] (3 responses)
When KDE started out there were no other free desktop environments (there were lots of free applications but nothing that tried to present a unified »look and feel« similar in scope to, say, that of the Mac). KDE took its inspiration from CDE, which at the time wasn't free at all. You can't really cause fragmentation if you're the first on the scene.
Personally I would of course have preferred to see a free desktop environment based on something like Tk rather than Qt. However, the KDE developers did not see fit to consult me before they got started ;^) You would have to ask them (more specifically, Matthias Ettrich) to find out exactly why they picked Qt. There is some information about their reasoning available on the KDE web site, but that very likely includes some hindsight.
Posted Jul 6, 2013 19:20 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
GTK developers faced the same exact situation, except that they were against proprietary Qt.
Posted Jul 6, 2013 19:33 UTC (Sat)
by anselm (subscriber, #2796)
[Link] (1 responses)
Your comment only tells us that you apparently haven't done much with Tk.
The GNOME people took an atrocious toolkit (Gtk) that had very little traction at the time and was barely good enough to support one single application (The GIMP) and spent massive effort to make it into something they could use for their written-from-scratch desktop environment. They could have put the same sort of effort into Tk and made it into something vastly better with less work. Tk, for its flaws, is really quite well-engineered and well-documented and it would have been absolutely feasible at the time to build a desktop environment based on it (at least as much so as building one based on what was then Gtk). I'd personally be inclined to think the main reason the GNOME people didn't do that is NIH and/or ignorance and/or not wanting to work with the Tk community.
Posted Jul 6, 2013 20:59 UTC (Sat)
by mpr22 (subscriber, #60784)
[Link]
Posted Jul 5, 2013 1:11 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
BTW, actually try look at commercial Unix software - I think most of it used GTK back then.
Oh, and if we're talking about fragmentation - why hasn't KDE used Motif? After all, it's totally free with JUST a $5000 per developer pricetag! I totally can't imagine why people would decide to write something that doesn't require forking over tons of bucks, with a vendor lock-in.
Posted Jul 5, 2013 7:11 UTC (Fri)
by anselm (subscriber, #2796)
[Link] (1 responses)
However bad Qt may have been at the time, Gtk was many times worse. Its main raison d'être was supporting The GIMP, and it took a major effort on the part of the early GNOME crowd to get it anywhere near where Qt was. Which, looking back, seems all the more silly given that there were better free alternatives around – and supports the thesis that GNOME was at least as much about NIH than it was about Qt licensing.
That which didn't use Motif or even other things like Tk which were more popular. (Tcl/Tk used to be pretty big in the (commercial) VLSI design scene, for example.) AFAIR, Gtk at the time had a fairly small slice of the cake as far as commercial development went.
Posted Jul 5, 2013 7:16 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link]
>Which, looking back, seems all the more silly given that there were better free alternatives around – and supports the thesis that GNOME was at least as much about NIH than it was about Qt licensing.
> That which didn't use Motif or even other things like Tk which were more popular. (Tcl/Tk used to be pretty big in the (commercial) VLSI design scene, for example.) AFAIR, Gtk at the time had a fairly small slice of the cake as far as commercial development went.
Posted Jul 3, 2013 12:05 UTC (Wed)
by maxiaojun (guest, #91482)
[Link]
Posted Jul 3, 2013 12:27 UTC (Wed)
by maxiaojun (guest, #91482)
[Link] (1 responses)
Why bother do so?
Remember the old quote? "I guess you have to decide if you are a GNOME app, an Ubuntu app, or an XFCE app unfortunately. I'm sorry that this is the case but it wasn't GNOME's fault that Ubuntu has started this fork. And I have no idea what XFCE is or does sorry."
Source: https://trac.transmissionbt.com/ticket/3685#comment:4
In many cases Web app is a better choice.
Posted Jul 3, 2013 23:33 UTC (Wed)
by bojan (subscriber, #14302)
[Link]
Yeah, if only everything on the desktop could be solved with that approach. Unfortunately, real desktop still needs real applications - which is what actually distinguishes the desktop from the new breed of devices.
Posted Jul 3, 2013 15:37 UTC (Wed)
by AdamW (subscriber, #48457)
[Link] (4 responses)
Posted Jul 3, 2013 15:41 UTC (Wed)
by AdamW (subscriber, #48457)
[Link]
Posted Jul 3, 2013 22:07 UTC (Wed)
by bojan (subscriber, #14302)
[Link] (2 responses)
Posted Jul 4, 2013 4:40 UTC (Thu)
by AdamW (subscriber, #48457)
[Link] (1 responses)
Posted Jul 5, 2013 0:32 UTC (Fri)
by bojan (subscriber, #14302)
[Link]
Yeah, the bar for Fedora QA is even lower and yet this many desktops are clearly not testable.
> In general I would expect that a third-party app designed to be 'desktop neutral' would run fine on *all* of them if it ran fine on *any* of them.
In general - very general.
In practice, if say Adobe wanted PhotoShop to work on Linux (say top 5 distros and all supported desktops they ship), they would have to perform regression testing against all combinations and they would have to make sure the software actually installs on all these different systems. That is a lot of effort for 1% market share with no clear direction "winner".
We can pretend it's something else, but IMHO it's just fragmentation.
Posted Jul 3, 2013 10:43 UTC (Wed)
by hadrons123 (guest, #72126)
[Link] (3 responses)
An updated image which is not tested as much as the release is better than the "broken caja which brings the system down". Can't the QA guys make this as an exception for the users since its too big to be neglected?
Posted Jul 3, 2013 15:38 UTC (Wed)
by AdamW (subscriber, #48457)
[Link] (2 responses)
Posted Jul 3, 2013 16:44 UTC (Wed)
by hadrons123 (guest, #72126)
[Link] (1 responses)
Posted Jul 3, 2013 18:44 UTC (Wed)
by AdamW (subscriber, #48457)
[Link]
We don't really do official respins, but once there's a confirmed fix for the bug, Dan and I may throw up a strictly unofficial respin somewhere.
Posted Jul 3, 2013 14:07 UTC (Wed)
by drag (guest, #31333)
[Link]
Looking through the bug report it seems like less of a problem with Fedora and more of a problem with Mate supported a confusing array of semi-obsolete ways of launching applications at user's log in.
This issue, I believe, has mostly been solved on KDE or Gnome.
Too bad that Mate so confusing that even the spin authors can't figure out how to do it right.
> depressingly Poor QA for the all the RH money spent on the quality.
If you want to find out what Redhat spent it's money on then don't use Mate.
I upgraded three systems to Fedora 19 by running "fedup --network 19" this weekend. Two systems upgraded without a hitch. One system doesn't boot anymore. It gives me the emergency prompt after a minute delay. That system uses a SATA controller that is RAID capable. Even though I never wanted to use RAID, an earlier version of Fedora created a RAID setup involving device-mapper and dmraid. It looks like that boot script waits for the device with the given UUID to appear and then gives up. I'm not sure where to report it, as I don't know which component is at fault. It's also possible that an older version of Fedora is to blame for making "RAID" with one drive without asking the user. But the new Fedora should then fix such setup.
First imressions
First imressions
First imressions
Fedora 19 released
Fedora 19 released
Fedora 19 released
Fedora 19 released
Fedora 19 released
http://blog.linuxgrrl.com/2013/03/04/refreshing-storage/
Fedora 19 released
Fedora 19 released
Fedora 19 released
Well, antiquated or not, I probably use suspend-to-disk (aka "Hibernate") four or more times each day on my main "workstation" (I use the term loosely). Mainly because suspend-to-ram (aka "Suspend") no longer works. It did at one time, but any more when I select that option the machine suspends but momentarily, then resumes on its own accord. I'll have to check its BIOS to see if there's some flaky bits in there which need tweaking, but I don't recall ever seeing any. Its a niche-vendor custom mini-itx MB with custom AMI BIOS to match, and I've never been particularly impressed. Fedup doesn't seem to work either, at least not from F17 to F18 which is what I've tried. Mostly it leaves me clueless -- no big trick -- but on reboot the new fedup kernel sometimes mentions an incorrect BIOS value, suggests perhaps its time for a new one, and hangs.
Fedora 19 released
Fedora 19 released
Fedora 19 released
Fedora 19 released
Fedora 19 released
Fedora 19 released
Fedora 19 released
Fedora 19 released
Fedora 19 released
Fedora 19 released
Fedora 19 released
Off-topic desktop whinge, unrelated to Fedora per se
Off-topic desktop whinge, unrelated to Fedora per se
Off-topic desktop whinge, unrelated to Fedora per se
Off-topic desktop whinge, unrelated to Fedora per se
Off-topic desktop whinge, unrelated to Fedora per se
Off-topic desktop whinge, unrelated to Fedora per se
Off-topic desktop whinge, unrelated to Fedora per se
Off-topic desktop whinge, unrelated to Fedora per se
Off-topic desktop whinge, unrelated to Fedora per se
Off-topic desktop whinge, unrelated to Fedora per se
Off-topic desktop whinge, unrelated to Fedora per se
Off-topic desktop whinge, unrelated to Fedora per se
Off-topic desktop whinge, unrelated to Fedora per se
Off-topic desktop whinge, unrelated to Fedora per se
Off-topic desktop whinge, unrelated to Fedora per se
Off-topic desktop whinge, unrelated to Fedora per se
Sure, and the Boston bomber is simply an angel, compared to Hitler. Why people want to keep him imprisoned?
Nope. Cloning was never a solution, from the legal standpoint.
Off-topic desktop whinge, unrelated to Fedora per se
Cloning was never a solution, from the legal standpoint.
Also, you might note that Mono right now is actually used on more machines than the total amount of classic Linux desktops.
Off-topic desktop whinge, unrelated to Fedora per se
Off-topic desktop whinge, unrelated to Fedora per se
It turns out that it's far easier to re-implement an existing API when you have a large workforce funded by the sale of a business than it is when you're a college student.
Off-topic desktop whinge, unrelated to Fedora per se
Microsoft explicitly allowed cloning, by standardizing .NET. They've also granted a royalty-free license for their patents on core .NET technologies.
See above.
Off-topic desktop whinge, unrelated to Fedora per se
Any realistic API-compatible clone of QT would be deemed a derived work because of the overwhelming number of literal copying that'll be required.
But Qt is C++, which means a lot of the implementation can be in the interface. For example qlist.h contains the entire QList implementation (mostly as templates). On the one hand, it would take an expert to figure out what you can change without breaking compatibility. On the other hand, it's 900 lines of complicated code and it seems unlikely that a court will decide there's no creative expression in there.
Off-topic desktop whinge, unrelated to Fedora per se
Off-topic desktop whinge, unrelated to Fedora per se
Off-topic desktop whinge, unrelated to Fedora per se
Off-topic desktop whinge, unrelated to Fedora per se
Now think about it, suppose that I spent $100^500 to clone QT - what do I achieve?
Off-topic desktop whinge, unrelated to Fedora per se
Off-topic desktop whinge, unrelated to Fedora per se
Nope, GTK creation was an entirely logical step at that time. Dislike of C++ might have played a role, but it wasn't decisive.
Off-topic desktop whinge, unrelated to Fedora per se
Off-topic desktop whinge, unrelated to Fedora per se
Off-topic desktop whinge, unrelated to Fedora per se
Off-topic desktop whinge, unrelated to Fedora per se
Off-topic desktop whinge, unrelated to Fedora per se
Off-topic desktop whinge, unrelated to Fedora per se
Maybe they perceived Tk as strongly coupled to Tcl, and didn't like Tcl.
Off-topic desktop whinge, unrelated to Fedora per se
Off-topic desktop whinge, unrelated to Fedora per se
Off-topic desktop whinge, unrelated to Fedora per se
Most ISVs simply looked at Linux and decided it's not worth it to fork over tons of dollars just for a crappy UI toolkit (and QT _was_ a crappy UI toolkit back then).
BTW, actually try look at commercial Unix software - I think most of it used GTK back then.
Off-topic desktop whinge, unrelated to Fedora per se
Duh. So what? It was obvious that some time will be required to reach a level where GTK is better than QT for most applications.
Which alternatives? Lesstif? Or maybe early EFL?
VMWare used it, several commercial suite also used it. Then lots of software started to use Eclipse which on Linux is based on GTK.
Off-topic desktop whinge, unrelated to Fedora per se
Off-topic desktop whinge, unrelated to Fedora per se
Off-topic desktop whinge, unrelated to Fedora per se
Off-topic desktop whinge, unrelated to Fedora per se
Off-topic desktop whinge, unrelated to Fedora per se
Off-topic desktop whinge, unrelated to Fedora per se
Off-topic desktop whinge, unrelated to Fedora per se
Off-topic desktop whinge, unrelated to Fedora per se
Fedora 19 released
I know. I like Dan too. I have reported my observations on that bug too.
>It is clearly not an easy fix.
I understand.
>What do you want us to do? Delay the entire Fedora 19 release indefinitely (since we clearly have no reliable timeframe for a fix) due to a superficial bug in a single fairly new desktop spin?
I don't expect to delay the entire F19 release. But when you have released the OS already, how about an updated image of MATE-LiveCD alone when the bug is fixed, since the bug is reasonably troublesome when it involves the file manager and bringing the system down for the sake of the users?
Fedora 19 released
Fedora 19 released
Fedora 19 released
Fedora 19 released