As someone involved in hiring engineers sometimes - tweets, no. At least in my field, social media is pretty much a convenience thing: if you use it to keep in touch with people, fine, but it wouldn't cross my mind to look at your twitter profile to judge your hireability. You don't _need_ a blog, but a long-standing blog with thoughtful posts on engineering issues would obviously be a plus for a candidate. If it was screamingly obvious you'd just started one while you were applying for work and were trying to tailor it to look good for potential employers, though...well, I suppose it would at least show you were making an effort.
really, when you're looking for good engineers you're looking for the whole identity. I don't think it's a big problem if you're not Google-able: you just need to make sure you provide some good supporting information to potential employers directly. Provide extensive samples of code you've written, first of all. Ideally, provide entire repositories complete with history, to prove that you understand how to work with source control properly. At least for me, I'm not checking off a list of 'current buzz technologies' you're involved with, I just want to know if you're someone who understands how to write good code in a co-operative way.
"RedHat on the other hand released RHEL 6.4 and removed crmsh, the configuration system for Pacemaker, to be replaced with PCS. This wasn't documented in the release notes, either. Suddenly things that configure high-availability fail-over on RHEL 6 don't work. Running the same tools/scripts/whatnot breaks. This is still RHEL 6 stable, and under Debian policy that's not supposed to happen. RedHat doesn't have such a policy, so it happens."
Well, that's not entirely accurate. Pacemaker is a Technology Preview in RHEL 6. This is a term with a very precise meaning (documented in your support contract and whatknot): https://access.redhat.com/site/solutions/21101 .
"Technology Preview features are currently unsupported, may not be functionally complete, and are not suitable for deployment in production. However, these features are provided to the customer as a courtesy and the primary goal is for the feature to gain wider exposure with the goal of full support in the future."
Given those attributes, it's not generally considered a big deal to change TPs in non-compatible ways in point releases. A change to an actual supported RHEL feature would be a much bigger deal.
"Well, at the risk of making myself into a pariah around Silicon Valley, I have a prediction to make"
Sigh. I hate people who write that kind of silly crap. If you're so worried about your image in some kind of idiotic Silicon Valley nerd club, your opinion is likely to be entirely irrelevant.
I'm not sure we're not talking at cross-purposes, but the thing we basically did to spite Oracle (can you tell I'm not in corporate communications?) was make our kernel sources a big glob instead of carefully splitting out the individual patches we were applying. That doesn't have any particular consequences for a distro that just wants to build whatever RH is building; it's only a problem if you want to claim you know exactly what's going on. You know, like someone who's selling...professional support....might want to...
I don't know if there's another issue you're referring to, though, I don't actually *use* RHEL or CentOS myself at all (only Fedora). I could have written something more specific, though, which would have communicated my meaning better: RH doesn't actively take decisions with the intent of causing problems for freely-distributed RHEL clones, whereas we certainly could start doing that if we chose to. It's possible that choices RH makes for other goals might sometimes cause them inconvenience, I don't discount the possibility.
RH isn't really in the business of telling people what database to use. We provide all the major ones, including pgsql. You can pick whichever you want to run.
We haven't had any problem at all replacing MySQL with MariaDB in Fedora per se.
MySQL folks wanted to keep MySQL in Fedora *too*, and we had some fun figuring out the packaging and upgrade paths such that both new-world-MySQL and MariaDB could be in Fedora with MariaDB replacing old-world-MySQL on F18->F19 upgrades, but RHEL will very easily avoid all that by simply not including new-world-MySQL (I expect).
It's a core principle of RH work that as much work as possible is done or pushed upstream, and that RH products should be 100% F/OSS (the exception to this is when we acquire proprietary software and spend a couple of years doing the legal and engineering spadework to make it 100% F/OSS, which is just a terrible thing for us to do, I know).
All of the source for RHEL is publicly available - http://ftp.redhat.com/pub/redhat/linux/enterprise/6Server/en/os/SRPMS/ (and other paths on that server), go knock yourself out. (This is not minimal legal compliance, BTW; minimal legal compliance would be providing only copyleft sources, and providing them only to customers. We don't have to put the entire SRPM set up for public download on our own servers). You can get an evaluation version of RHEL 6 for free at https://ca.redhat.com/products/enterprise-linux/server/download.html - where 'evaluation' just means 'you only get updates for X days'. You can buy the RHEL Developer Suite - https://www.redhat.com/apps/store/developers/rhel_developer_suite.html - which includes RHEL with every single add-on, and access to all updates, just like having a commercial support contract only without the commercial support - for a measly $99. Or you can just go download CentOS or Scientific Linux, which projects RH does nothing whatsoever to impede.
So, which OpenStack provider would you trust instead, which has been around for more than 5 years (the length of time between the first RH release in 1998 and the point where 'Red Hat Linux' turned into Fedora around 2003) and has never discontinued a single product?
Just contact your old client and ask if they'll write up a letter for you, affirming that you wrote the code for them, for you to use for job search purposes only. There's no reason to assume there was any particular malice in them putting their company headers on the code, so there's no reason to go down an adversarial path immediately. You've got nothing to lose by just asking them politely to acknowledge you as the author of the code for this specific scenario, and doing so establishes that you're acting in good faith, so why not do it?
Good point, but in my head it was even simpler: the implication of her statement is that we could have conducted a reasonable discussion of the merits of the programs just so long as we knew nothing at all about them. Which pretty much sums up the absurdity of the position the NSA is currently occupying.
You pretty much *have* to say something like that to get elected to high office in the U.S. It seems to be a pre-requisite for the office to declare, at some point, that you are on a mission from God.
Speaking as a bleeding heart liberal, it doesn't seem an improvement to stop locking people in secret prisons without access to lawyers and start killing them with drones instead.
Erm, I work for Red Hat too. I know there's this meme that Red Hat cares a lot about GNOME for some reason, but we really really don't.
RH sponsors GNOME development because it's one of the major F/OSS desktops, and someone has to. We used to be just one out of many companies who did; most of them have now fallen by the wayside and it's mostly us.
There is no 'implicit pressure' at RH for engineers to use any desktop whatsoever. No-one cares. There are people at RH using GNOME, KDE, Xfce, LXDE, MATE, blackbox, fluxbox, openbox, any other box you care to name, Windows, and OS X, and any other desktop or WM I forgot to put in that list. The RH 'standard desktop distro' for use by non-engineering staff uses GNOME (2) because it's basically RHEL 6 and we have to standardize on something. But if you're in engineering you can use whatever the hell you like as long as your job gets done.
Red Hat pays several people who work on KDE as well as people who work on GNOME, and the Fedora Xfce spin is maintained by a Red Hat employee (Kevin Fenzi). In Fedora, KDE and GNOME have equal support status: both are required to meet the same quality requirements as part of release validation.
There isn't anything about Mir. I think Phoronix made a booboo in their summary. It was only intended to explain some things about Wayland, Mir is out of scope.
You never needed to append 'init=/sbin/init', just '3' was enough. And just '3' still works with systemd: it translates single numerals to the corresponding systemd target, so passing '3' boots multi-user.target, which is the same as 'runlevel 3' (multi-user, non-graphical).
I do QA for Fedora, so I spend quite a bit of time poking all the major desktops.
I spent a bit of time last week poking around with how GNOME and KDE handle keyboard configuration. It's a *classic* example of the philosophical difference between them.
GNOME 3 has spent a lot of time trying to figure out how to get it right for most people, most of the time, with the absolute minimum possible amount of options. How GNOME does it is that it queries xkb for the valid layouts, and gives you a very very simple configuration dialog which shows you the few most common layouts (and iBus IMEs), progressively revealing more and more obscure ones till you have most of the full set. It does not provide any method for configuring XkbOptions (there is one in gnome-tweak-tool) and it overrides xkb's layout switching config (though this is slated to change for 3.10, I think).
This is good for maybe 90-95% of users; they can pick their keyboard layout with zero fuss. If you're someone who needs to tweak an XkbOption, though, it's kind of a pain in the ass, and GNOME basically forks the systemwide xkb configuration for each new user account, so after your user account is created and initially configured, changes to the systemwide config will not be reflected in any way in your user config.
Contrast KDE. Now, KDE can do *everything*. It can do everything because its keyboard configuration tool is a very thin GUI around xkb configuration: it literally just gives you every possible thing you can set in xkb as a drop-down, radio button, checkbox or text entry. Every. Single. Damn. Thing. Including one option which will do absolutely nothing for 99.99% of PC users these days, the XkbModel option (which mostly just sets the 'geometry' of the keyboard, which is used for one thing - rendering keyboard layout previews - and KDE's preview layout widget doesn't even *use* it). And it has a checkbox (of course! a checkbox!) for whether your user should just use the system-wide xkb settings, or have its own KDE settings that override those.
This makes the people who like to call themselves 'power users' happy because OOH LOOK LOTS OF OPTIONS. It is genuinely useful for the minority of people who actually need to set some XkbOption *and know what it is*. But it's tiresome and confusing and potentially dangerous for the majority of people who don't totally understand how Xkb works (which is, like, just about everyone). And KDE does this for *every damn thing*. I would love it if someone went and counted every damn checkbox in the KDE control center, and I defy a single person to know what every one of the bloody things does.
I dunno, especially as a QA guy, I get mental fatigue just looking at the KDE control center. It's overwhelming. Exposing every possible setting certainly innoculates you against the problem that someone somewhere can't set the options they need, but it sure confuses the hell out of people. Personally I find the GNOME approach more elegant - even though sometimes they make mistakes and go too far in simplification, the goal they're aiming for is a worthy one and they're iterating towards it, _generally_ getting better over time. The KDE approach seems almost like a cop-out, to me.
You have to read the whole series of articles, not just the first one.
Notably, the final paragraph of the concluding article:
"When I started this experiment, I was expecting that it would be an interesting foray and that I’d most likely end up switching back to KDE when it was all over. I’m no longer certain that I will be doing that.
I’ve been fairly comfortable operating in GNOME Classic, once I figured out the few tweaks I needed to perform. I think I’m probably going to continue using GNOME Classic for a while (at least until after next week’s Red Hat Summit)."
"When I started this experiment, I was expecting that it would be an interesting foray and that I’d most likely end up switching back to KDE when it was all over. I’m no longer certain that I will be doing that.
I’ve been fairly comfortable operating in GNOME Classic, once I figured out the few tweaks I needed to perform. I think I’m probably going to continue using GNOME Classic for a while (at least until after next week’s Red Hat Summit)."
Slashdot Mirror
As someone involved in hiring engineers sometimes - tweets, no. At least in my field, social media is pretty much a convenience thing: if you use it to keep in touch with people, fine, but it wouldn't cross my mind to look at your twitter profile to judge your hireability. You don't _need_ a blog, but a long-standing blog with thoughtful posts on engineering issues would obviously be a plus for a candidate. If it was screamingly obvious you'd just started one while you were applying for work and were trying to tailor it to look good for potential employers, though...well, I suppose it would at least show you were making an effort.
really, when you're looking for good engineers you're looking for the whole identity. I don't think it's a big problem if you're not Google-able: you just need to make sure you provide some good supporting information to potential employers directly. Provide extensive samples of code you've written, first of all. Ideally, provide entire repositories complete with history, to prove that you understand how to work with source control properly. At least for me, I'm not checking off a list of 'current buzz technologies' you're involved with, I just want to know if you're someone who understands how to write good code in a co-operative way.
"RedHat on the other hand released RHEL 6.4 and removed crmsh, the configuration system for Pacemaker, to be replaced with PCS. This wasn't documented in the release notes, either. Suddenly things that configure high-availability fail-over on RHEL 6 don't work. Running the same tools/scripts/whatnot breaks. This is still RHEL 6 stable, and under Debian policy that's not supposed to happen. RedHat doesn't have such a policy, so it happens."
Well, that's not entirely accurate. Pacemaker is a Technology Preview in RHEL 6. This is a term with a very precise meaning (documented in your support contract and whatknot): https://access.redhat.com/site/solutions/21101 .
"Technology Preview features are currently unsupported, may not be functionally complete, and are not suitable for deployment in production. However, these features are provided to the customer as a courtesy and the primary goal is for the feature to gain wider exposure with the goal of full support in the future."
Given those attributes, it's not generally considered a big deal to change TPs in non-compatible ways in point releases. A change to an actual supported RHEL feature would be a much bigger deal.
"Well, at the risk of making myself into a pariah around Silicon Valley, I have a prediction to make"
Sigh. I hate people who write that kind of silly crap. If you're so worried about your image in some kind of idiotic Silicon Valley nerd club, your opinion is likely to be entirely irrelevant.
I'm not sure we're not talking at cross-purposes, but the thing we basically did to spite Oracle (can you tell I'm not in corporate communications?) was make our kernel sources a big glob instead of carefully splitting out the individual patches we were applying. That doesn't have any particular consequences for a distro that just wants to build whatever RH is building; it's only a problem if you want to claim you know exactly what's going on. You know, like someone who's selling...professional support....might want to...
I don't know if there's another issue you're referring to, though, I don't actually *use* RHEL or CentOS myself at all (only Fedora). I could have written something more specific, though, which would have communicated my meaning better: RH doesn't actively take decisions with the intent of causing problems for freely-distributed RHEL clones, whereas we certainly could start doing that if we chose to. It's possible that choices RH makes for other goals might sometimes cause them inconvenience, I don't discount the possibility.
RH isn't really in the business of telling people what database to use. We provide all the major ones, including pgsql. You can pick whichever you want to run.
We haven't had any problem at all replacing MySQL with MariaDB in Fedora per se.
MySQL folks wanted to keep MySQL in Fedora *too*, and we had some fun figuring out the packaging and upgrade paths such that both new-world-MySQL and MariaDB could be in Fedora with MariaDB replacing old-world-MySQL on F18->F19 upgrades, but RHEL will very easily avoid all that by simply not including new-world-MySQL (I expect).
Yeah, I only learned about it from Thomas Cameron at LFNW this year! I actually had no idea we sold that :P
Red Hat is the sole, most significant contributor or one of the main contributors to to an awful lot of those 'other open source projects':
https://fedoraproject.org/wiki/Red_Hat_contributions (and that's massively incomplete)
It's a core principle of RH work that as much work as possible is done or pushed upstream, and that RH products should be 100% F/OSS (the exception to this is when we acquire proprietary software and spend a couple of years doing the legal and engineering spadework to make it 100% F/OSS, which is just a terrible thing for us to do, I know).
All of the source for RHEL is publicly available - http://ftp.redhat.com/pub/redhat/linux/enterprise/6Server/en/os/SRPMS/ (and other paths on that server), go knock yourself out. (This is not minimal legal compliance, BTW; minimal legal compliance would be providing only copyleft sources, and providing them only to customers. We don't have to put the entire SRPM set up for public download on our own servers). You can get an evaluation version of RHEL 6 for free at https://ca.redhat.com/products/enterprise-linux/server/download.html - where 'evaluation' just means 'you only get updates for X days'. You can buy the RHEL Developer Suite - https://www.redhat.com/apps/store/developers/rhel_developer_suite.html - which includes RHEL with every single add-on, and access to all updates, just like having a commercial support contract only without the commercial support - for a measly $99. Or you can just go download CentOS or Scientific Linux, which projects RH does nothing whatsoever to impede.
RH is the single leading contributor to upstream OpenStack: http://readwrite.com/2013/04/16/will-red-hats-openstack-contributions-turn-to-gold
Name me a company that manages to run a sustainable business while contributing more to F/OSS development. One company.
So, which OpenStack provider would you trust instead, which has been around for more than 5 years (the length of time between the first RH release in 1998 and the point where 'Red Hat Linux' turned into Fedora around 2003) and has never discontinued a single product?
...make you think it's a really good idea to zap vague areas of your brain with electricity based on the hilariously incomplete field of neuroscience?
Canadian farmers stand to do pretty well, for a start.
Just contact your old client and ask if they'll write up a letter for you, affirming that you wrote the code for them, for you to use for job search purposes only. There's no reason to assume there was any particular malice in them putting their company headers on the code, so there's no reason to go down an adversarial path immediately. You've got nothing to lose by just asking them politely to acknowledge you as the author of the code for this specific scenario, and doing so establishes that you're acting in good faith, so why not do it?
Good point, but in my head it was even simpler: the implication of her statement is that we could have conducted a reasonable discussion of the merits of the programs just so long as we knew nothing at all about them. Which pretty much sums up the absurdity of the position the NSA is currently occupying.
You pretty much *have* to say something like that to get elected to high office in the U.S. It seems to be a pre-requisite for the office to declare, at some point, that you are on a mission from God.
Speaking as a bleeding heart liberal, it doesn't seem an improvement to stop locking people in secret prisons without access to lawyers and start killing them with drones instead.
Yeah, and the principle is absurd. Can you fly a plane into Boeing's AGM?
Erm, I work for Red Hat too. I know there's this meme that Red Hat cares a lot about GNOME for some reason, but we really really don't.
RH sponsors GNOME development because it's one of the major F/OSS desktops, and someone has to. We used to be just one out of many companies who did; most of them have now fallen by the wayside and it's mostly us.
There is no 'implicit pressure' at RH for engineers to use any desktop whatsoever. No-one cares. There are people at RH using GNOME, KDE, Xfce, LXDE, MATE, blackbox, fluxbox, openbox, any other box you care to name, Windows, and OS X, and any other desktop or WM I forgot to put in that list. The RH 'standard desktop distro' for use by non-engineering staff uses GNOME (2) because it's basically RHEL 6 and we have to standardize on something. But if you're in engineering you can use whatever the hell you like as long as your job gets done.
Red Hat pays several people who work on KDE as well as people who work on GNOME, and the Fedora Xfce spin is maintained by a Red Hat employee (Kevin Fenzi). In Fedora, KDE and GNOME have equal support status: both are required to meet the same quality requirements as part of release validation.
There isn't anything about Mir. I think Phoronix made a booboo in their summary. It was only intended to explain some things about Wayland, Mir is out of scope.
You never needed to append 'init=/sbin/init', just '3' was enough. And just '3' still works with systemd: it translates single numerals to the corresponding systemd target, so passing '3' boots multi-user.target, which is the same as 'runlevel 3' (multi-user, non-graphical).
No, it isn't. He says he "likes the hot corner thing". Fallback mode does not have a hot corner.
Yes. This.
I do QA for Fedora, so I spend quite a bit of time poking all the major desktops.
I spent a bit of time last week poking around with how GNOME and KDE handle keyboard configuration. It's a *classic* example of the philosophical difference between them.
GNOME 3 has spent a lot of time trying to figure out how to get it right for most people, most of the time, with the absolute minimum possible amount of options. How GNOME does it is that it queries xkb for the valid layouts, and gives you a very very simple configuration dialog which shows you the few most common layouts (and iBus IMEs), progressively revealing more and more obscure ones till you have most of the full set. It does not provide any method for configuring XkbOptions (there is one in gnome-tweak-tool) and it overrides xkb's layout switching config (though this is slated to change for 3.10, I think).
This is good for maybe 90-95% of users; they can pick their keyboard layout with zero fuss. If you're someone who needs to tweak an XkbOption, though, it's kind of a pain in the ass, and GNOME basically forks the systemwide xkb configuration for each new user account, so after your user account is created and initially configured, changes to the systemwide config will not be reflected in any way in your user config.
Contrast KDE. Now, KDE can do *everything*. It can do everything because its keyboard configuration tool is a very thin GUI around xkb configuration: it literally just gives you every possible thing you can set in xkb as a drop-down, radio button, checkbox or text entry. Every. Single. Damn. Thing. Including one option which will do absolutely nothing for 99.99% of PC users these days, the XkbModel option (which mostly just sets the 'geometry' of the keyboard, which is used for one thing - rendering keyboard layout previews - and KDE's preview layout widget doesn't even *use* it). And it has a checkbox (of course! a checkbox!) for whether your user should just use the system-wide xkb settings, or have its own KDE settings that override those.
This makes the people who like to call themselves 'power users' happy because OOH LOOK LOTS OF OPTIONS. It is genuinely useful for the minority of people who actually need to set some XkbOption *and know what it is*. But it's tiresome and confusing and potentially dangerous for the majority of people who don't totally understand how Xkb works (which is, like, just about everyone). And KDE does this for *every damn thing*. I would love it if someone went and counted every damn checkbox in the KDE control center, and I defy a single person to know what every one of the bloody things does.
I dunno, especially as a QA guy, I get mental fatigue just looking at the KDE control center. It's overwhelming. Exposing every possible setting certainly innoculates you against the problem that someone somewhere can't set the options they need, but it sure confuses the hell out of people. Personally I find the GNOME approach more elegant - even though sometimes they make mistakes and go too far in simplification, the goal they're aiming for is a worthy one and they're iterating towards it, _generally_ getting better over time. The KDE approach seems almost like a cop-out, to me.
You have to read the whole series of articles, not just the first one.
Notably, the final paragraph of the concluding article:
"When I started this experiment, I was expecting that it would be an interesting foray and that I’d most likely end up switching back to KDE when it was all over. I’m no longer certain that I will be doing that.
I’ve been fairly comfortable operating in GNOME Classic, once I figured out the few tweaks I needed to perform. I think I’m probably going to continue using GNOME Classic for a while (at least until after next week’s Red Hat Summit)."
GNOME Classic is not GNOME Fallback. They're two very different things. The post from "magic maverick" - http://tech.slashdot.org/comments.pl?sid=3832435&cid=43930125 - explains it well.
Er. No. He didn't.
"When I started this experiment, I was expecting that it would be an interesting foray and that I’d most likely end up switching back to KDE when it was all over. I’m no longer certain that I will be doing that.
I’ve been fairly comfortable operating in GNOME Classic, once I figured out the few tweaks I needed to perform. I think I’m probably going to continue using GNOME Classic for a while (at least until after next week’s Red Hat Summit)."
Score needs to go to 6 for this one.