I have 2xU2211H, both oriented portrait. I can see having one landscape if you need to work on video or something, but I don't.
I'd always go for the smallest display at a given resolution, to get the highest DPI: I much prefer 22" 1920x1080 to 24" 1920x1080. Still, I wish someone would make 200+ DPI desktop displays. Some day.
"Toxic Influence is an ongoing series of reports exploring the nexus between industry, science and policy. This story is being produced in partnership with the Center for Public Integrity."
Basically, they're digging through recent history to find questionable stuff that wasn't really highlighted at the time.
"Big organizations are evil! If we went back to having small, personal, friendly organizations, everything would be better!" is a popular meme these days but it just isn't realistic, if you look at it dispassionately. We have big organizations because there are more of us, and we're doing very complex and advanced things. You only really need five people at Bob's Bakery Inc. to supply your town with bread, okay, but you can't have five people at Bob's Car Factory Inc. supply your town with cars, and fifty thousand people at Bob's Multinational Food Corp can, without question, supply your town with bread more efficiently than Bob's Bakery Inc. Sorry. It doesn't fit in with our romantic notions of How Things Ought To Be, but it's how they are.
I wish people would get over this vaguely sepia-tinted bourgeois fantasy where somehow we manage to supply several billion people with their expected quality of living via some sort of utopian version of the late Victorian economy, and start coming up with answers to the much more practical - but less zeitgeisty and much more _difficult_ - problem of 'how do we make large organizations more responsive to the concerns of the individual, where that's practical and desirable?'. That's a question worth asking and trying to answer.
I think the point here is that 'brogrammer' is a completely artificial concept that has been imposed upon from without by a bunch of journalists looking for an angle, and we should stop accepting it and just call 'bullshit' every time the term is used.
I've never met or even heard of anyone it makes any damn sense to describe as a 'brogrammer'. As the term was initially 'defined' a few months back, it certainly wouldn't apply to Zuckerberg. Now it's just a meaningless label being thrown on worthless clickbait articles by worthless journalists. If we just ignore it, maybe it'll go away.
"This transition has been going on for over a year now"
I know - with scant regard to the fact that there is still zero hardware acceleration support for 10-bit. None, zip, zero, nada. Knowing 'this transition' is going on doesn't do you much good if you actually need hardware accelerated playback. My whole point is that this started with one or two groups and now lots of others are jumping on the _bandwagon_ without waiting for playback capabilities to catch up...
Even with multithreaded software decoding you need a pretty powerful CPU to keep up with HD hi10p; so far as media centre boxes go you pretty much need something from the most recent CPU generation. My previous-gen Zotac box can now play _most_ 720p files with little framedrop, but it still doesn't stand a chance of keeping up with most 1080p stuff.
It's kind of weird to cut out anyone who's not using a powerful current-gen PC from playing your stuff, especially now streamer boxes are so common and there are big communities of people using e.g. RasbPi and Apple TV boxes as XBMC platforms. They don't stand a hope in hell of playing anything their hardware decoders don't support.
I know which groups use 8 and which use 10, but not all stuff is available from 8-bit groups.
it enables multithreaded decoding of hi10p content (and *only* hi10p, it won't enable multithreading for anything else, where it could potentially be buggy). Since there's nothing at all capable of hardware decoding hi10p at present, this is a huge boon for those of us trying to watch HD hi10p files on little media server boxes. It takes typical hi10p files from 'visibly jerky' to 'nearly perfect' on my zotac box. OpenELEC 3.0 rc2 has this patch built in, as it comes from an openelec dev; other XBMC users might want to add it to their setups.
So what you're saying is that RHEL should contain things that originate in Fedora but are improved and bugfixed before inclusion in RHEL? Well, that sounds radical, but it might just work...
"but evolution ignored all my old configuration (and the configuration backup I made)"
evo moved a bunch of stuff from gconf to gsettings between 3.4 and 3.6. Nothing specific to f18, you'll see issues with this particular version upgrade in any distro when it happens. Seems like you hit a weirdly bad case, though, usually it just loses a few settings that they forgot to carry over.
"As of today, all these things are completely broken in F18 and the new installer."
No they are not. You may be having problems with them, in which case sorry, but it is not correct to say they are completely broken, as they are not.
We tested kickstart installs extensively during F18 validation and they work fine. Just fine. In fact they're the part of install that has changed least since F17. It is impossible to help you with whatever problem you're seeing without any details at all, but it is definitely not the case that kickstarts are 'completely broken'.
On "password-protect GRUB" - see the other guy's response. It is not 'completely broken'. The default behaviour of password protection changed upstream between grub1 and grub2; we are following upstream behaviour. 'Restoring' the grub1 behaviour is, as the other guy said, not as straightforward as it might seem.
"lock out users from accessing a shell on/dev/tty2 during installation"
This seems like an odd thing to talk about. Are you saying you want to do that but you can't? Or what? Details.
"expect GDM to show up (or, heck, Xorg to run) after doing an automated install"
Works fine in testing.
"require that updated packages be installed during automated installation"
Kickstart install uses the repos you define. Define repos that include updates and updates will be installed. Don't, and they won't. It's entirely up to you. This has not changed at all between F17 and F18.
"Now....how can I implement something of this sort?"
It's called 'subcontracting'. Set yourself up a corporation, bid on some code contracts, buy some purchasing managers some dinners, you'll be well on your way to millions and self-loathing. Double dip!
It's already available in RPM. There's periodic discussion about using it in Fedora, but the discussion always turns to perfectly valid theoretical scenarios in which soft dependencies can cause problems. I'd still like to see us use them on the basis that in *practice* there's a perfectly respectable RPM-based distro out there which has been using them for years and has been able to manage any problems which come up - Mandriva/Mageia - but the naysayers have a valid point at least in theory, soft dependencies make dependency management a lot more complex and can result in some pretty broken corner cases.
yep, the place is cargo cult central. stick with builds of the major ROMs from affiliated devs, is my advice. Run like hell from the threads which are kangs of those builds with some kid's AWESOME BLACK THEME and a bunch of kernel patches he picked up somewhere.
"that e-books are well suited to some types of books (like genre fiction) but not well suited to other types (like...literary fiction)"
I can see 'nonfiction' (the bit I elided) as non-linear reading is still a pain on ebooks. But this one just baffled me. 'Genre fiction' and 'literary fiction' both consist in the main of your classic 350 page novel, in chapters, read in order: how can ebooks possibly be suited to one but not to the other?
Oh right! I forgot. Most literary fiction 'readers' don't read their literary fiction, they just leave it lying around prominently to let everyone know how intellectual they are. You can't do that with an ebook. Got it.
What, you couldn't understand that? It's perfectly simple! Here, let me summarize: words words words words spin words words words negative words words words FRICKIN LASER
"Anyway, are there really people out there dumb enough to accept a computer from ANY source and use it without completely reformatting it and reinstalling their own OS?"
Yes. Hell, people have done studies where they left USB keys lying in the parking lots of major corporations. People happily took 'em inside, plugged them in and starting copying confidential data to them.
also note that the anaconda team is small. If we'd gone ahead with F18 with oldUI, very little work would have been done on newUI between F18 Alpha and Final, because the anaconda team would inevitably have got sucked into the usual round of blocker fix work. So it might have resulted in newUI being delayed not to F19, but to F20...etc...etc...every release we went with oldUI made a _significant_ dent in work on newUI.
The problem with that is that it's a very difficult call to make. It's pretty much _always_ the case that something isn't done. At some point, you _need_ to have the New Shiny in main where everyone is paying attention to it and testing it and hacking on. You can only get so much work and testing done on a major component in a side branch.
Personally I think it might possibly have worked better to put off the merge till F19 or schedule a longer F18 cycle, but at the same time, I don't think you can reasonably quantify the decision taken at the time as flat wrong. It's a very difficult judgment call to make and I don't think it's reasonable to look at it as a binary 'right or wrong' thing. Hindsight is always great, but it's much harder to make these calls five months before a release point.
I haven't tried it with btrfs. subvol support isn't entirely complete, it's true. This hardly represents a regression, though, as there was _no_ interactive support for btrfs in f17, we just dropped it out of the installer entirely for that release. Implementing anything close to 'full' btrfs support is a very big job, because it's got so many damn features - it's like writing support for LVM, RAID and a couple of other storage technologies, from the ground up, all at once...
But yes, it definitely works for LVM now. I checked. That bug probably needs some updating, it looks to have got lost in the mix at some point.
There is a help screen for the custom partitioning UI in TC4 (and will be for final, obviously). It uses a different approach to most partitioning interfaces and figuring that out at first can be a bit tricky. We're looking at ways to make it somewhat more discoverable in F19. It does pretty much work pretty solidly in F18, though, for most uses, once you figure out the design. It's been pretty heavily tested.
Slashdot Mirror
I have 2xU2211H, both oriented portrait. I can see having one landscape if you need to work on video or something, but I don't.
I'd always go for the smallest display at a given resolution, to get the highest DPI: I much prefer 22" 1920x1080 to 24" 1920x1080. Still, I wish someone would make 200+ DPI desktop displays. Some day.
Footer reads:
"Toxic Influence is an ongoing series of reports exploring the nexus between industry, science and policy. This story is being produced in partnership with the Center for Public Integrity."
Basically, they're digging through recent history to find questionable stuff that wasn't really highlighted at the time.
"How can this idea be made better?"
It can't. It's a crap idea.
"Big organizations are evil! If we went back to having small, personal, friendly organizations, everything would be better!" is a popular meme these days but it just isn't realistic, if you look at it dispassionately. We have big organizations because there are more of us, and we're doing very complex and advanced things. You only really need five people at Bob's Bakery Inc. to supply your town with bread, okay, but you can't have five people at Bob's Car Factory Inc. supply your town with cars, and fifty thousand people at Bob's Multinational Food Corp can, without question, supply your town with bread more efficiently than Bob's Bakery Inc. Sorry. It doesn't fit in with our romantic notions of How Things Ought To Be, but it's how they are.
I wish people would get over this vaguely sepia-tinted bourgeois fantasy where somehow we manage to supply several billion people with their expected quality of living via some sort of utopian version of the late Victorian economy, and start coming up with answers to the much more practical - but less zeitgeisty and much more _difficult_ - problem of 'how do we make large organizations more responsive to the concerns of the individual, where that's practical and desirable?'. That's a question worth asking and trying to answer.
I think the point here is that 'brogrammer' is a completely artificial concept that has been imposed upon from without by a bunch of journalists looking for an angle, and we should stop accepting it and just call 'bullshit' every time the term is used.
I've never met or even heard of anyone it makes any damn sense to describe as a 'brogrammer'. As the term was initially 'defined' a few months back, it certainly wouldn't apply to Zuckerberg. Now it's just a meaningless label being thrown on worthless clickbait articles by worthless journalists. If we just ignore it, maybe it'll go away.
I'm a paid-up subscriber to all available legal services, thanks.
"This transition has been going on for over a year now"
I know - with scant regard to the fact that there is still zero hardware acceleration support for 10-bit. None, zip, zero, nada. Knowing 'this transition' is going on doesn't do you much good if you actually need hardware accelerated playback. My whole point is that this started with one or two groups and now lots of others are jumping on the _bandwagon_ without waiting for playback capabilities to catch up...
Even with multithreaded software decoding you need a pretty powerful CPU to keep up with HD hi10p; so far as media centre boxes go you pretty much need something from the most recent CPU generation. My previous-gen Zotac box can now play _most_ 720p files with little framedrop, but it still doesn't stand a chance of keeping up with most 1080p stuff.
It's kind of weird to cut out anyone who's not using a powerful current-gen PC from playing your stuff, especially now streamer boxes are so common and there are big communities of people using e.g. RasbPi and Apple TV boxes as XBMC platforms. They don't stand a hope in hell of playing anything their hardware decoders don't support.
I know which groups use 8 and which use 10, but not all stuff is available from 8-bit groups.
If you're forced to watch a lot of hi10p stuff (thanks, bandwagon-jumping fansub groups!) you may want to grab this patch:
https://github.com/xbmc/xbmc/pull/2064
it enables multithreaded decoding of hi10p content (and *only* hi10p, it won't enable multithreading for anything else, where it could potentially be buggy). Since there's nothing at all capable of hardware decoding hi10p at present, this is a huge boon for those of us trying to watch HD hi10p files on little media server boxes. It takes typical hi10p files from 'visibly jerky' to 'nearly perfect' on my zotac box. OpenELEC 3.0 rc2 has this patch built in, as it comes from an openelec dev; other XBMC users might want to add it to their setups.
subject should read: "Elon Musk Offers Boeing SpaceX Batteries For the Free Publicity"
I think we're talking 'spoiled' in the sense of 'spoilers follow!', not in the sense of 'ruined'.
So what you're saying is that RHEL should contain things that originate in Fedora but are improved and bugfixed before inclusion in RHEL? Well, that sounds radical, but it might just work...
"but evolution ignored all my old configuration (and the configuration backup I made)"
evo moved a bunch of stuff from gconf to gsettings between 3.4 and 3.6. Nothing specific to f18, you'll see issues with this particular version upgrade in any distro when it happens. Seems like you hit a weirdly bad case, though, usually it just loses a few settings that they forgot to carry over.
"As of today, all these things are completely broken in F18 and the new installer."
No they are not. You may be having problems with them, in which case sorry, but it is not correct to say they are completely broken, as they are not.
We tested kickstart installs extensively during F18 validation and they work fine. Just fine. In fact they're the part of install that has changed least since F17. It is impossible to help you with whatever problem you're seeing without any details at all, but it is definitely not the case that kickstarts are 'completely broken'.
On "password-protect GRUB" - see the other guy's response. It is not 'completely broken'. The default behaviour of password protection changed upstream between grub1 and grub2; we are following upstream behaviour. 'Restoring' the grub1 behaviour is, as the other guy said, not as straightforward as it might seem.
"lock out users from accessing a shell on /dev/tty2 during installation"
This seems like an odd thing to talk about. Are you saying you want to do that but you can't? Or what? Details.
"expect GDM to show up (or, heck, Xorg to run) after doing an automated install"
Works fine in testing.
"require that updated packages be installed during automated installation"
Kickstart install uses the repos you define. Define repos that include updates and updates will be installed. Don't, and they won't. It's entirely up to you. This has not changed at all between F17 and F18.
"Now....how can I implement something of this sort?"
It's called 'subcontracting'. Set yourself up a corporation, bid on some code contracts, buy some purchasing managers some dinners, you'll be well on your way to millions and self-loathing. Double dip!
It's already available in RPM. There's periodic discussion about using it in Fedora, but the discussion always turns to perfectly valid theoretical scenarios in which soft dependencies can cause problems. I'd still like to see us use them on the basis that in *practice* there's a perfectly respectable RPM-based distro out there which has been using them for years and has been able to manage any problems which come up - Mandriva/Mageia - but the naysayers have a valid point at least in theory, soft dependencies make dependency management a lot more complex and can result in some pretty broken corner cases.
I'm not sure how this is 'informative' when it's an assertion backed by precisely zero evidence.
...you could just press the Super key. which brings up everything you can alternatively bring up using an edge or corner.
yep, the place is cargo cult central. stick with builds of the major ROMs from affiliated devs, is my advice. Run like hell from the threads which are kangs of those builds with some kid's AWESOME BLACK THEME and a bunch of kernel patches he picked up somewhere.
Kindle did that. It was called the Kindle DX. No-one bought it.
(Kobo currently makes both 5" and 6" versions of their reader, fwiw, Sony used to but I'm not sure if they still do).
What we *really* need is stretchable screens!
"that e-books are well suited to some types of books (like genre fiction) but not well suited to other types (like...literary fiction)"
I can see 'nonfiction' (the bit I elided) as non-linear reading is still a pain on ebooks. But this one just baffled me. 'Genre fiction' and 'literary fiction' both consist in the main of your classic 350 page novel, in chapters, read in order: how can ebooks possibly be suited to one but not to the other?
Oh right! I forgot. Most literary fiction 'readers' don't read their literary fiction, they just leave it lying around prominently to let everyone know how intellectual they are. You can't do that with an ebook. Got it.
What, you couldn't understand that? It's perfectly simple! Here, let me summarize: words words words words spin words words words negative words words words FRICKIN LASER
"Anyway, are there really people out there dumb enough to accept a computer from ANY source and use it without completely reformatting it and reinstalling their own OS?"
Yes. Hell, people have done studies where they left USB keys lying in the parking lots of major corporations. People happily took 'em inside, plugged them in and starting copying confidential data to them.
also note that the anaconda team is small. If we'd gone ahead with F18 with oldUI, very little work would have been done on newUI between F18 Alpha and Final, because the anaconda team would inevitably have got sucked into the usual round of blocker fix work. So it might have resulted in newUI being delayed not to F19, but to F20...etc...etc...every release we went with oldUI made a _significant_ dent in work on newUI.
The problem with that is that it's a very difficult call to make. It's pretty much _always_ the case that something isn't done. At some point, you _need_ to have the New Shiny in main where everyone is paying attention to it and testing it and hacking on. You can only get so much work and testing done on a major component in a side branch.
Personally I think it might possibly have worked better to put off the merge till F19 or schedule a longer F18 cycle, but at the same time, I don't think you can reasonably quantify the decision taken at the time as flat wrong. It's a very difficult judgment call to make and I don't think it's reasonable to look at it as a binary 'right or wrong' thing. Hindsight is always great, but it's much harder to make these calls five months before a release point.
I haven't tried it with btrfs. subvol support isn't entirely complete, it's true. This hardly represents a regression, though, as there was _no_ interactive support for btrfs in f17, we just dropped it out of the installer entirely for that release. Implementing anything close to 'full' btrfs support is a very big job, because it's got so many damn features - it's like writing support for LVM, RAID and a couple of other storage technologies, from the ground up, all at once...
But yes, it definitely works for LVM now. I checked. That bug probably needs some updating, it looks to have got lost in the mix at some point.
There is a help screen for the custom partitioning UI in TC4 (and will be for final, obviously). It uses a different approach to most partitioning interfaces and figuring that out at first can be a bit tricky. We're looking at ways to make it somewhat more discoverable in F19. It does pretty much work pretty solidly in F18, though, for most uses, once you figure out the design. It's been pretty heavily tested.
"The problem is almost 100% the new installer that basically is not all that different from the old one."
Er. It is hugely, massively different from the old one. It's virtually an entire new code base.