Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

ekimd writes "Fedora 17 aka "Beefy Miracle" is released. Some of the major features include: ext4 with >16TB filesystems, dynamic firewall configuration, automatic multi-seat, and more. Major software updates include Gnome 3.4, GIMP 2.8, and GCC 4.7. The full feature list can be found here. Personally, I still find Gnome 3 to be an 'unholy mess' so I'm loving XFCE with Openbox."

For whatever reason, I find it to be hilarious. I'm not much of a fan of Ubuntu's naming scheme, but this one from Fedora struck a chord with me. I guess it's my inner 12 year old that finds this amusing.

Unfortunately a lot of linux distro coders don't seem to know where the dividing line between wryly amusing and lame is when it comes to naming releases. The novelty of Ubuntus silly release names wore off for me personally around 5 years ago. All I want a OS so please just stick with the release numbers and don't treat me like a 7 year ago girl looking for a new cuddly toy.

Names are useful for the creative team who doesn't know which backend their creative materials (look and feel) are going with. When the creative starts, it might be Fedora 16.2, 17, 17.5, 18... Apple has proven that these names from creative can be used for branding and Debian... have followed suit.

Names are useful for the creative team who doesn't know which backend their creative materials (look and feel) are going with. When the creative starts, it might be Fedora 16.2, 17, 17.5, 18...

I have no problems working on features and fixes for future Linux kernel versions without needing to know what actual version name the release will be called. I don't see how the distro developers can't do the same thing.

i like debian's release names cos my whole family is a fan of toy story. dunno what they gunna do when the list of character names runs out though. maybe then they can go with finding nemo, another excellent pixar classic:)

The most significant difference between Fedora and Ubuntu here is that in Fedora, the only time you're likely to see a release name is on a Slashdot article, and then if you look at/etc/issue*. Everybody else calls it Fedora 17. In Ubuntuland everybody calls the release by at least the noun part of the release name. For Fedora, its terribly inconsequential, and I say that as the guy who named Fedora 12.

The ONLY way your argument is at all legitimate is if extensions is included with the default software that comes with Gnome 3. Because it sure seems like it is needed. To chip in, the new alt tab sucks, I wish it would "regress."

Actually i think it was more of a "copy macosx" behavior kind of move. It's not really bad or good in my experience. depending on the workflow one or the other might be more convenient. Since apps tend to be single window, I tend to prefer the previous switching however, but since apps tend to be single windows.. the new switching also tend to look like just the old switching, making it less of an issue.

My reading comprehension is just fine. You throw around insults because a GUI dares not do things the way you expect. Rather than stepping back and perhaps considering the rationale for this decision, or maybe, just maybe offering constructive criticism you start ranting and insulting people. Immature doesn't begin to cover it. Grow up.

I guess the question being, what scenario is more productive? If you have small window count of about one window per app, then you probably wouldn't have even *noticed* the difference. If you have a large window count, then how does alt-tab, alt-above-tabe impede productivity? Other arguments I can buy (e.g. encouraging many across-the-screen moves, hiding dock making it more difficult to be 'discoverable', and many other criticisms of gnome 3), but other than 'it's different', I see no technical advanta

Either you do a window-based DE or an application based, Gnome 3 went for application based. I happen to like it, a lot. this includes alt-tab behavior. If you happen do not like application based, then you should probably not try to turn Gnome 3 into one, there are other choices for you.

I think Gnome 3 is the best thing that happened to the *nix desktop for a long time. The navigation is fast if you know how to use it. I do use a few extensions, like static workspaces (altough I think this is included in 3.4). It also happen to be quite fast, running it on my ion2 netbook, no problem. Have never used a composition desktop before, they where all to slow. Gnome 3 changed that.

Gnome developers have always had cojones and done things which may not look to be the right thing, in the end they come out winning, this time should not be an exception.

I find whether you like gnome3 is highly dependent on how many applications you typically have open at once, with the fewer you have open the more usable gnome being.

The eeepc I'm on at present has (counts) 43 windows open, and on my desktop I can be using 100+ depending upon task. Quickly accessing the window I want under gnome3 is a real pain compared to say, kde. So I just use kde.

The grandparents get by with gnome3 just fine though, they rarely have more than 4-5 things open at a time.

The KDE option is their for those that don't like Gnome3. Now I drive Dodge trucks so should I whine and bitch about Chevys and what an unholy mess their electrical systems are? And Timothy there are many different desktops if you don't know how to install a different DE use Ubuntu and STF up.

... which is always fun to talk about. Fedora is really pushing the state of Linux forward more than any other distro.systemd for faster boot and starter reactions to changes (eg USB device plugged in). Moving every thing to/usr to make the filesystem more sane.Single window gimp! And lots more.

Of course, you can still use/usr in a separate filesystem from / if you boot with an initrd, but you now almost need half an operating system (busybox, rescue shell and utilities, perhaps support for lvm and/or RAID) just to boot your real operating system.

Why would you want/usr on a separate filesytem? Perhaps you want it in LVM, so you can resize it easily if necessary (maybe to make room for installing a new desktop environment, for example), but don't want you root file system in LVM. Perhaps you want to periodically fsck/usr on boot, and fall into single-user mode if it fails. Perhaps you want/usr (which is a read-mainly file system) on a small SSD, and all other file systems (which are written to more frequently) on spinning disk storage. Perhaps you want to mount/usr over NFS. Not that I can still see many people doing this but it seems a pity to prevent something that has worked fine in the past - and in these days of "running applications in the cloud" it seems Linux will no longer run applications in the local network (ie. NFS-mounted/usr).

Seriously, read the level of professionalism and maturity on that page. This is the level or maturity to which Linux slowly seems to be sinking. As a long-time Linux user and supporter I find this deeply disappointing.

And what's the reason for all this? Because the udev developers can't wipe their own a{r|s}es, put their house in order, and properly sort out which files go where (or at least sort out what needs to be done to mount any necessary non-root filesystems, mount them, and then continue with any programs/scripts which use them). Instead, all of that gets pushed out to initrd (ie. oh no it's hard, let's give it to someone else to do). Seriously, they're like a bunch of 8-year-olds bragging to their friends that they won't clean their bedrooms, even when mummy thinks they should.

One thing I'm wondering - how improved is their package management? As I've noted in the past, apt-get is far more advanced, and on the BSD side of things, so is PBI. So has Fedora/Red Hat done anything to enable packages in rpm format to be more easily installed, as in not run into dependency hell?

Also, how does Fedora compare w/ other rpm based distros, such as Mageia, Mandriva, PCLinuxOS and so on?

It isn't the packaging tools that make Debian and the BSDs more consistent in package installation. If anything, RPM has more advanced features than either debs or ports. The Debian and various ports repositories have standard practices for naming, versioning, dependencies, and integration that are adhered to year after year. It is concern for the long term integrity of these package repositories AS A WHOLE that make them easy to deal with. But bullet point differences between Deb and RPM? Not so much.

Debian based distros also tend to limit themselves in how they diverge from the Debian Mothership and periodically resync in any case. I routinely port source packages between Ubuntu and Debian all the time. Since the naming and dependency maps don't diverge much, I mostly succeed at doing this. On the other hand, a SUSE SRPM isn't likely to port easily to Fedora absent a lot of low level surgery on the package metadata. Each RPM distro tends to be an island universe. Deb based distros all have Debian for a parent or grandparent hence the high compatibility at the source level.

For that matter RHEL and spinoffs like Centos and Scientific mostly achieve this as well though the experience is mostly like using Debian Stable without the option of (easily) backporting SRPMS from newer distros.

Yum is pretty solid. There are only two things that kind of bug me about it:

1. Sometimes (especially when dealing with third-party repos e.g. RPM Fusion) you'll see what looks like the same package listed 4 times. My guess is that there is a separate package for each architecture. Simply omitting the package portion from the name when you run the install command seems to pick the correct package(s). Still a bit confusing though, especially in cases where there are other compounding factors like differen

Setting up the third-party repos isn't as dummy-proof as setting up PPAs in Ubuntu. (It's a pretty straightforward but largely manual process, unless I'm missing something. And if I'm missing something, then that is a problem in itself.)

It's one click in a web browser, though it would be nice if the system itself had a option to install it, even if it gave you a "you're being naughty and installing non-free stuff" warning. You also have to know it exists in the first place.

One thing I'm wondering - how improved is their package management? As I've noted in the past, apt-get is far more advanced

People who still ask this question tend not to have used yum/rpm in about a decade.

That is just not true. I've used a cheap virtual machine with limited memory ( 512 MB) for hosting stuff, and I'm waiting for my Raspberry Pi to arrive which has 256 MB memory.

Using yum on such systems is utter, and complete, pain. It will simply not work with anything less than a gig of memory. Apt however, will work flawlessly. There is VERY MUCH room for improvement concerning package management.

I've pulled down large updates including openoffice on a Linux equipped PS3 so I know yum works on systems with low RAM. The real stickler is protectbase if you use ps3bodega, protectbase slows yum down a lot. But the thing works with less than a gig of RAM.

Interesting; apparently your use case precludes the memory problems I've seen. Have you ever run "yum update", in which it encountered a libc update? Or perhaps an update to an X library? Basically anything that has a large number of dependencies. Also, you're increasing the memory we're talking about, we started with 512 MB, and you're now saying it works with less than a gig of RAM.

For about two years, I've administrated three RedHat 5 systems, which were upgraded every now and then until they reached 5.5. The memory on those systems varied between 128 and 512 MB memory, two were virtualized with Xen. It seemed that 384 MB was the lower limit for these systems to run "yum update" without hitting swap. These were standard LAMP webservers. Often, I'd shut down MySQL, Apache and Postfix to run yum.

Anyway, since you say you did fine with 256 MB, I'm going to revisit the scenario, and see

I'm not sure if you're trolling, but apt-get has never been more advanced than yum (at least, not since yum was included in Fedora). Notable features of yum that apt-get lacks include the ability to install a package from a local file, resolving and installing its dependencies from repositories, and the ability to resolve and install a package given a path or the name of a feature it "Provides". Yum's a little slower than apt-get, but it's definitely the more capable of the two.

That's a fair question. I use Openbox with XFCE because you can customize keybindings for any kind of window manipulation you like - shoving windows to the left and right border, resizing, vertical maximizing, flipping between workspaces...

It's a nice middle-of-the-road solution for people who are sick and tired of fiddling with windows with the mouse but aren't ready to go whole hog with a tiling WM or setting up a desktop with panels, etc. from scratch.

You don't need another spin, since kde/xfce etc come on the install dvd.

Aside from emergency recovery situations, there is no reason to use livecds any more. If you are going to install an os do a full install, not an extermely gimped install just so your install media is the size of an old school cd.

With developer tools and a whole lot more stuff than most sane people need my fedora installs tend to hit 6-8gb max, this is nothing for hard disks/ssd today.

I just find that everything I do in gnome 3 takes more steps...ie more clicks, more resizing, more drilling down, and on top of it all one additional click that does nothing more then get you off that useless page that is your faux desktop. For me and the way I use my computers this is not a step forward, but two steps back.
If gnome 3 was on a smart phone, or a tablet, and I ran one application at a time, it would be pretty, and get the job done. But I run this on a desktop computer with fair horse power,

Show all Windows for an app: Maybe I'm missing something but I use Cycle through the apps with Alt-TAB, Cycle throught the windows for an app with Alt-AboveTAB. Which means to cycle through the windows for the current app, one press of Alt-AboveTAB shows the set. I use the cursor keys in Alt-TAB to navigate as well - not sure that is in Vanilla Gnome 3.4.

Thanks for that. I do wish the window previews were a bit more usably large (as it stands, the thumbnail is just too small to make out wtf it is).

The alt-tab behavior you describe is vanilla, but when you have dozens of terminals and you *know* a substring in a title, a search is more effective than traversing. If referring to it being a substitute for 'show all windows for an app', the problem being the UI in compize/kde uses maybe 90% of screen real estate to facilitate decipherable previews, where alt-

You do realize that the Fedora leadership expressly does *not* want to be part of corporate applications right? From a business perspective, the goal is to have a research and development strategy that takes advantage of enthusiasts willingness to have a less stable environment to test and develop features and concepts that ultimately land in 'Red Hat Enterprise Linux', the most popular 'enterprisy' instance of Linux there is?