CentOS 7 does not currently support Nvidia Pascal GPU's out of the box so if you are running into issues with the graphical installer then it's a safe bet that it's because you have a Pascal card in your machine. You can work around this by using the text-based installer but partitioning isn't as full-featured so you might be forced to use the automatic partitioning option.
Once CentOS is installed you can simply download the proprietary Nvidia drivers - which work quite nicely I might add - and be up and running with your desktop in no time. As long as you know how to navigate the commandline until you get the proper drivers installed then it shouldn't be much of a challange.
I have a GTX 1080 in my workstation and the graphical installer hung while systemd was initializing. You'd think at least VESA graphics would work on Pascal GPU's but it doesn't - at least not currently. Hopefully the CentOS installation disks will be updated at some point to at least include rudimentary GTX 10XX support.
Showing posts with label Linux. Show all posts
Showing posts with label Linux. Show all posts
Saturday, July 22, 2017
Friday, January 4, 2013
Was udev a bad idea? Not at first.
I'm not an expert when it comes to device handling on Linux but I have written udev rules in the past (since 071 and earlier) and do have some familiarity, and at the time udev was first introduced it looked like an excellent solution. In fact, I felt it was a welcomed change from devfs. Not so long ago time came to upgrade to 105, and boy was I surprised - these days udev really looks like shit.
It sure doesn't seem like udev's design has scaled very well. For instance, udev rules you wrote even 6 month ago are unlikely to work with the most recent version because they keep changing the syntax every few releases. Why would stuff like $modalias suddenly be changed to a much uglier $env{MODALIAS}? I'm curious to know why anyone would favor such a syntax.
Also, udev 071 consisted of a fairly small set of binaries, but later releases grew to pretty much one helper program for each device class, and you are now expected to do stuff like copy pre-made symlinks and device nodes manually into the /dev directory. If anything, wasn't that supposed to be udev's job in the first place? A nice improvement is that udev 071+ completely replaces hotplug for the 2.6 kernel - which is perhaps the reason for all the helper programs.. I'm not entirely sure. I still think it could have been done a lot cleaner, though.
udev rules used to be something that could be written in a very clean and comprehensible style, but now you'll get a headache just by looking at basic examples. Quite frankly I'm starting to dislike it more and more and sometimes find myself wishing for it to just go away. After looking at FreeBSD and how clean /dev is kept I'm starting to wonder if it really was such a great idea to abandon devfs all together.
Update: The above is an old post. Since then udev was merged into systemd - a rat's nest of a init system that I'm forced to use daily, fortunately the eudev fork exists.
It sure doesn't seem like udev's design has scaled very well. For instance, udev rules you wrote even 6 month ago are unlikely to work with the most recent version because they keep changing the syntax every few releases. Why would stuff like $modalias suddenly be changed to a much uglier $env{MODALIAS}? I'm curious to know why anyone would favor such a syntax.
Also, udev 071 consisted of a fairly small set of binaries, but later releases grew to pretty much one helper program for each device class, and you are now expected to do stuff like copy pre-made symlinks and device nodes manually into the /dev directory. If anything, wasn't that supposed to be udev's job in the first place? A nice improvement is that udev 071+ completely replaces hotplug for the 2.6 kernel - which is perhaps the reason for all the helper programs.. I'm not entirely sure. I still think it could have been done a lot cleaner, though.
udev rules used to be something that could be written in a very clean and comprehensible style, but now you'll get a headache just by looking at basic examples. Quite frankly I'm starting to dislike it more and more and sometimes find myself wishing for it to just go away. After looking at FreeBSD and how clean /dev is kept I'm starting to wonder if it really was such a great idea to abandon devfs all together.
Update: The above is an old post. Since then udev was merged into systemd - a rat's nest of a init system that I'm forced to use daily, fortunately the eudev fork exists.
Friday, September 28, 2012
Good practices - A plea to open source projects
I compile, configure and test the software used on mainstream Linux distributions. I do this on a private distribution (for personal use) and at the moment it consists of slightly more than 1000 (no, this is not a typo) build scripts, which I have written myself. I maintain the init scripts and all package builds in the entire Linux distribution software stack - everything from the kernel, glibc, to the compiler toolchain all the way up to Xorg and KDE. I even wrote a scripted package manager to aid me in my task and automate the process, I haven't switched to it yet but plan to eventually. Needless to say, I know my way around Linux fairly well. Because I package so much of the Linux software stack I also know many of the dirty little secrets we hide from end users behind our crafted packages. Users are often oblivious about how much trouble package maintainers have to go through just to get their favorite application compiled, packaged and ready to be executed.
About 90% of the software projects I encounter are well behaved, well structured and well designed. It's that last 10% I spend 90% of my time with trying to get up and running, for whatever reason. This is what this post is all about - saving time and frustration.
My beef with the current state of open source/free software is the departure from traditional UNIX software engineering principles. Software projects today seem to ignore stuff like FHS (File Hierarchy Standard) and basics of the Unix Philosophy. One rule is - write simple parts connected by clean interfaces. I see this and other principles violated left and right, and blatant violations of FHS are not uncommon. Read the FHS, trust me - it won't take long. This will allow you to understand the beauty of the UNIX filesystem layout, there is practically a directory assigned for everything you might think of, and once you understand it you'll appreciate how elegant it is. People with a background on Windows systems rarely understand nor appreciate why the directory layout looks the way it does on UNIX-like operating systems but once you do I'm sure you'll grow to love the logic behind it. At first glance it looks cryptic, but there's a reason for that - and the benefits are still there today in spite of it's long history. It isn't as complex as you might think. For example, if you've written a library then it belongs in /lib or /usr/lib (depending on what kind of library it is, a core os library would belong in /lib while a less crucial library belongs in /usr/lib). Does your server program need to write data somewhere? Have a look at /var. Is your application a desktop application and need to write data somewhere? Do it in a dot directory somewhere in the users $HOME path. Do you have static data that should be availabe system-wide? Stick it in /usr/share. That's what the FHS is for - it describes the filesystem and what all these directories are meant for.
There are brilliant programmers out there who write excellent programs but some of them haven't taken the time to understand these basics, and thus their programs, brilliant though they might be, behave in undesirable ways. It isn't exactly fun to dig through someones code and patch it to conform to the FHS. For people who package software this makes your application high-maintenance. A piece of advice to software engineers - take a long hard look at the build scripts and .spec files used by distributions to build and package your program, if it's riddled with hacks just to get it packaged then you should probably consider simplifying and correcting the build framework.
If you're using the GNU autotool framework to build your software then make sure it respects all the standard configure switches, and more importantly make really sure that DESTDIR works as it's supposed to, you'd be surprised how many software projects that neglect this particular feature, but it's essential for packaging the program. For aestethic (and some practical) reasons - avoid CamelCase in program names, don't use version numbers in paths - and if you need to then opt for /usr/include/app/$VERSION rather than /usr/include/app-$VERSION, we have pkg-config for a reason - it's handy for locating package-specific directories, and simplifies management of multiple versions of a program or library on the same system - no need to clutter the top level /usr/include directory.
Use relative rather than absolute symlinks for "make install", you don't want symlinks to point to the wrong files which is what will probably happen if your application resides on a mounted filesystem, and if it doesn't then the symlink will be broken. It also makes chroot jails easier - although I wouldn't expect anyone to design their application with this in mind. In the end it's just cleaner and better to always use relative symlinks.
Do NOT change the API unless you also change the major version number. Be patient, and if you desperately want to make changes to your API then wait until you are ready to release the next major version. Why? Because that's what we (downstream) are expecting - API changes in major version changes. Let me clarify why. For example, lets assume your library is widely used by other projects, but you descide to push a major API change in a point release. Oblivious to this change downstream updates to the new point release thinking it's API compatible with the previous point release you made. It will take time before we realize a dozen other applications no longer compile due to the change. Now we have to downgrade and recompile once more. I'd love to tell you that we always read ChangeLog's but sadly some of us just don't have the time.
Do NOT use unstable, in-development libraries and core component. This causes endless misery due to constant breakage. Wait until the API and design has stabilized and please, please don't make dependencies to svn/git/cvs versions. Unless stable tarballs have been released then don't hook your code into it's API. Gnome has always been a real PITA because they do this, and I've occasionally had to pull code from CVS just to get "just the right version" to make it work. I get it - you want the latest and greatest features but please, do not torment downstream with dependencies to unreleased code.
Digitally sign your code, ALWAYS. Make this a habit. While most people who download your code probably won't verify the signature you'll be glad you signed it if your code distribution site is hacked. It happens, and when it does it's one hell of a task to figure out what was tampered with.
On a more personal note I'd want to encourage projects to stick to a single compression format for releases rather than making three or four identical tarballs compressed with different algorithms that need to be signed independently. My suggestion? Stick to gzip. It decompresses faster than any other algorithm and while it's very inefficent when compared to LZMA2 (.xz) you'll only need to do the one tarball and just about everyone will be able to decompress it. A couple of years from now xz might be widespread enough to justify the switch.
ALWAYS include a license. Preferably as file named a COPYING or LICENSE in the top-level directory. A tarball without one is like getting a wrapped present that has a suspicious ticking noise. Sure, it could be just a harmless clock but it could also be a bomb. By including a license you make your intentions clear so we don't have to worry about getting sued for packaging and distributing your program. Use a common and widely used license - legalese isn't always easy to understand so by using a common (and scrutinized) license we can be sure there aren't any hidden surprises behind the wording.
Describe your software and include an official URL for the project. As strange as this might seem a lot of projects neglect these simple details. A short paragraph in a README file is more than enough and it allows us to figure our what it's for because it isn't always obvious. It's hard to identify the purpose of program or library by a name such as libsnx. By also including an official project URL you'll also save us a lot of time trying to search for the upstream distribution website when it's time to update and we can then be sure we've got the right project. Often there are a lot of alternative programs to perform a given task.
Modularity is great. It's encouraged by standard UNIX practices, but as a project grows and becomes increasingly more complex modularity tends to show it's limitations. It isn't always practical to keep 100 modules in sync on the code level, especially if you start making API changes.
Off the top of my head, that's about it for now.
About 90% of the software projects I encounter are well behaved, well structured and well designed. It's that last 10% I spend 90% of my time with trying to get up and running, for whatever reason. This is what this post is all about - saving time and frustration.
My beef with the current state of open source/free software is the departure from traditional UNIX software engineering principles. Software projects today seem to ignore stuff like FHS (File Hierarchy Standard) and basics of the Unix Philosophy. One rule is - write simple parts connected by clean interfaces. I see this and other principles violated left and right, and blatant violations of FHS are not uncommon. Read the FHS, trust me - it won't take long. This will allow you to understand the beauty of the UNIX filesystem layout, there is practically a directory assigned for everything you might think of, and once you understand it you'll appreciate how elegant it is. People with a background on Windows systems rarely understand nor appreciate why the directory layout looks the way it does on UNIX-like operating systems but once you do I'm sure you'll grow to love the logic behind it. At first glance it looks cryptic, but there's a reason for that - and the benefits are still there today in spite of it's long history. It isn't as complex as you might think. For example, if you've written a library then it belongs in /lib or /usr/lib (depending on what kind of library it is, a core os library would belong in /lib while a less crucial library belongs in /usr/lib). Does your server program need to write data somewhere? Have a look at /var. Is your application a desktop application and need to write data somewhere? Do it in a dot directory somewhere in the users $HOME path. Do you have static data that should be availabe system-wide? Stick it in /usr/share. That's what the FHS is for - it describes the filesystem and what all these directories are meant for.
There are brilliant programmers out there who write excellent programs but some of them haven't taken the time to understand these basics, and thus their programs, brilliant though they might be, behave in undesirable ways. It isn't exactly fun to dig through someones code and patch it to conform to the FHS. For people who package software this makes your application high-maintenance. A piece of advice to software engineers - take a long hard look at the build scripts and .spec files used by distributions to build and package your program, if it's riddled with hacks just to get it packaged then you should probably consider simplifying and correcting the build framework.
If you're using the GNU autotool framework to build your software then make sure it respects all the standard configure switches, and more importantly make really sure that DESTDIR works as it's supposed to, you'd be surprised how many software projects that neglect this particular feature, but it's essential for packaging the program. For aestethic (and some practical) reasons - avoid CamelCase in program names, don't use version numbers in paths - and if you need to then opt for /usr/include/app/$VERSION rather than /usr/include/app-$VERSION, we have pkg-config for a reason - it's handy for locating package-specific directories, and simplifies management of multiple versions of a program or library on the same system - no need to clutter the top level /usr/include directory.
Use relative rather than absolute symlinks for "make install", you don't want symlinks to point to the wrong files which is what will probably happen if your application resides on a mounted filesystem, and if it doesn't then the symlink will be broken. It also makes chroot jails easier - although I wouldn't expect anyone to design their application with this in mind. In the end it's just cleaner and better to always use relative symlinks.
Do NOT change the API unless you also change the major version number. Be patient, and if you desperately want to make changes to your API then wait until you are ready to release the next major version. Why? Because that's what we (downstream) are expecting - API changes in major version changes. Let me clarify why. For example, lets assume your library is widely used by other projects, but you descide to push a major API change in a point release. Oblivious to this change downstream updates to the new point release thinking it's API compatible with the previous point release you made. It will take time before we realize a dozen other applications no longer compile due to the change. Now we have to downgrade and recompile once more. I'd love to tell you that we always read ChangeLog's but sadly some of us just don't have the time.
Do NOT use unstable, in-development libraries and core component. This causes endless misery due to constant breakage. Wait until the API and design has stabilized and please, please don't make dependencies to svn/git/cvs versions. Unless stable tarballs have been released then don't hook your code into it's API. Gnome has always been a real PITA because they do this, and I've occasionally had to pull code from CVS just to get "just the right version" to make it work. I get it - you want the latest and greatest features but please, do not torment downstream with dependencies to unreleased code.
Digitally sign your code, ALWAYS. Make this a habit. While most people who download your code probably won't verify the signature you'll be glad you signed it if your code distribution site is hacked. It happens, and when it does it's one hell of a task to figure out what was tampered with.
On a more personal note I'd want to encourage projects to stick to a single compression format for releases rather than making three or four identical tarballs compressed with different algorithms that need to be signed independently. My suggestion? Stick to gzip. It decompresses faster than any other algorithm and while it's very inefficent when compared to LZMA2 (.xz) you'll only need to do the one tarball and just about everyone will be able to decompress it. A couple of years from now xz might be widespread enough to justify the switch.
ALWAYS include a license. Preferably as file named a COPYING or LICENSE in the top-level directory. A tarball without one is like getting a wrapped present that has a suspicious ticking noise. Sure, it could be just a harmless clock but it could also be a bomb. By including a license you make your intentions clear so we don't have to worry about getting sued for packaging and distributing your program. Use a common and widely used license - legalese isn't always easy to understand so by using a common (and scrutinized) license we can be sure there aren't any hidden surprises behind the wording.
Describe your software and include an official URL for the project. As strange as this might seem a lot of projects neglect these simple details. A short paragraph in a README file is more than enough and it allows us to figure our what it's for because it isn't always obvious. It's hard to identify the purpose of program or library by a name such as libsnx. By also including an official project URL you'll also save us a lot of time trying to search for the upstream distribution website when it's time to update and we can then be sure we've got the right project. Often there are a lot of alternative programs to perform a given task.
Modularity is great. It's encouraged by standard UNIX practices, but as a project grows and becomes increasingly more complex modularity tends to show it's limitations. It isn't always practical to keep 100 modules in sync on the code level, especially if you start making API changes.
Off the top of my head, that's about it for now.
Saturday, June 13, 2009
Mono - does it suck?
I just stumbled across an amusing rant in my RSS reader: Here we go again - Why Mono doesn't suck. Why do I find it amusing? Because this is probably the most disillusioned rant I've read in years. It goes from ranting about "anti-Mono movements", "Software Terrorism" to quoting Thomas Jefferson to accusations about persecution. Many gems in this piece I tell you. Extremist and bias is what I peg this sort of thing as, and it really is quite funny. He starts by claiming that he'll address certain points of concern like why Mono is not a threat to free software. Of course, in the end, he does no such thing.
Sunday, December 14, 2008
The hell that is Gnome and Xorg
Gnome and Xorg are fine pieces of software but they're a real pain to build. This is a rant I've been thinking about venting for a couple of years now.
First off, Xorg used to be OK when it had the monolithic build but then it split into hundreds of pieces and the maintenance overhead went up a hundredfold (for anyone who creates packages). It has become as tedious to build as Gnome.
Gnome has always been a pain, the developers say "modularity" is the brilliance underlying Gnome. Modularity is good. Modularity is excellent. Modularity makes things easier. But NOT when you break your project into a gazillion pieces. If you do that then it's just shattered. KDE understands this, their desktop is modular but "grouped" into larger packages, effectively turning it into a monolithic/modular hybrid. Basically, there is modularity within the packages while the packages themselves are monolithic. The advantage is that the desktop packages can be managed by a small group of people or even a single individual because the dependency chains become shorter. And you still get to keep modularity for developers. The disadvantage is that security patches become tougher to roll out because the packages become much bigger. With that in mind - I'll take one big package over a hundred small ones ANY day.
I am still using Xorg 6.9.0 because it's the last monolithic version of X. Why? I simply do not have the time to manage the modular Xorg - you need a team to do that or settle for a hackish build system (ala Slackware). Slackware's build system works well enough to ship modular X but if you take a closer look you'll notice the packages do not even have proper descriptions because there is simply too many of them to bother. In addition - broken down into so many small pieces it becomes much harder to understand what each piece is supposed to do. It's like puzzles - A few big pieces is easier to fit together than hundreds of very small ones.
Update: I switched to modular Xorg quite some time ago, my opinion remains the same however. In fact, to migrate I had to write a script that automatically generated the package build scripts for each tarball so I wouldn't have to do it all manually. Also interesting is that there are many bits of the modular Xorg that suffer from neglect and no longer compiles, this especially applies to drivers (there are dozens of drivers that for one reason or another has been abandoned yet is still included in the Xorg distribution).
First off, Xorg used to be OK when it had the monolithic build but then it split into hundreds of pieces and the maintenance overhead went up a hundredfold (for anyone who creates packages). It has become as tedious to build as Gnome.
Gnome has always been a pain, the developers say "modularity" is the brilliance underlying Gnome. Modularity is good. Modularity is excellent. Modularity makes things easier. But NOT when you break your project into a gazillion pieces. If you do that then it's just shattered. KDE understands this, their desktop is modular but "grouped" into larger packages, effectively turning it into a monolithic/modular hybrid. Basically, there is modularity within the packages while the packages themselves are monolithic. The advantage is that the desktop packages can be managed by a small group of people or even a single individual because the dependency chains become shorter. And you still get to keep modularity for developers. The disadvantage is that security patches become tougher to roll out because the packages become much bigger. With that in mind - I'll take one big package over a hundred small ones ANY day.
I am still using Xorg 6.9.0 because it's the last monolithic version of X. Why? I simply do not have the time to manage the modular Xorg - you need a team to do that or settle for a hackish build system (ala Slackware). Slackware's build system works well enough to ship modular X but if you take a closer look you'll notice the packages do not even have proper descriptions because there is simply too many of them to bother. In addition - broken down into so many small pieces it becomes much harder to understand what each piece is supposed to do. It's like puzzles - A few big pieces is easier to fit together than hundreds of very small ones.
Update: I switched to modular Xorg quite some time ago, my opinion remains the same however. In fact, to migrate I had to write a script that automatically generated the package build scripts for each tarball so I wouldn't have to do it all manually. Also interesting is that there are many bits of the modular Xorg that suffer from neglect and no longer compiles, this especially applies to drivers (there are dozens of drivers that for one reason or another has been abandoned yet is still included in the Xorg distribution).
Sunday, July 22, 2007
Gnomes and users
Recently Linus got into yet another spat on one of the Gnome mailing lists (an overblown incident IMO). It's hard not to get emotional about these things, and as someone who also gets frustrated by Gnome I can't help but cheer for Linus on this one. Feedback should be one of the most valuable sources of input Gnome could get regarding usability so you'd think they'd care, but unfortunately they don't. Instead, they hold interface guidelines (and their own conclusions about GUI design) in a much higher regard and leave a number of frustrated users behind. It's their right, of course, but perhaps also a mistake if the goal is to appeal to a wide user base. Not all of us subscribe to the Gnome project's idea of "simple is always better", and personally I doubt I'll ever learn to like it, well, at least not Gnome's approach which is to literally strip features away.
Certain Gnome developers are absolutely, positively convinced they're right too, and that's just creepy given how subjective GUI design is. In this particular case they even rationalized with an "it's been discussed before" argument. Consensus among Gnome developers translates into fact, apparently, but there's only one problem - GUI design is NOT an exact science regardless of what they might have you believe, and there is definitely a bias among Gnome regarding design.
I was also shocked when one of the Gnome developers implied that Linus was stupid because he didn't speak Spanish. I know that he (Linus) speaks at least three languages (incidentally the same ones I speak - English, Swedish and Finnish and I've heard him speak all of them) so it's not like he's linguistically challanged or anything. It can be an advantage to know several languages, true, but it doesn't make you intelligent any more than driving a porsche makes you important. We can't be expected to be sharp at all times though, and occasionally even the brightest among us make mistakes and say stupid things, so I think I'll cut the Gnome developer some slack for that reason alone. Still, the arrogance is stunning.
I wish Gnome would revert to what it used to be at around Gnome 2.6. It was OK back then. It still had it's fair share of problems but it somehow felt better and seemed less fragile. That was before they got all fanatic about interface guidelines and began copying OS X. I don't think Gnome is inherently bad. In fact, I find it quite enjoyable at times when I can bring myself to ignore certain quirks - like the supposedly "intuitive" file dialogs (a truly horrible design if there ever was one).
Certain Gnome developers are absolutely, positively convinced they're right too, and that's just creepy given how subjective GUI design is. In this particular case they even rationalized with an "it's been discussed before" argument. Consensus among Gnome developers translates into fact, apparently, but there's only one problem - GUI design is NOT an exact science regardless of what they might have you believe, and there is definitely a bias among Gnome regarding design.
I was also shocked when one of the Gnome developers implied that Linus was stupid because he didn't speak Spanish. I know that he (Linus) speaks at least three languages (incidentally the same ones I speak - English, Swedish and Finnish and I've heard him speak all of them) so it's not like he's linguistically challanged or anything. It can be an advantage to know several languages, true, but it doesn't make you intelligent any more than driving a porsche makes you important. We can't be expected to be sharp at all times though, and occasionally even the brightest among us make mistakes and say stupid things, so I think I'll cut the Gnome developer some slack for that reason alone. Still, the arrogance is stunning.
I wish Gnome would revert to what it used to be at around Gnome 2.6. It was OK back then. It still had it's fair share of problems but it somehow felt better and seemed less fragile. That was before they got all fanatic about interface guidelines and began copying OS X. I don't think Gnome is inherently bad. In fact, I find it quite enjoyable at times when I can bring myself to ignore certain quirks - like the supposedly "intuitive" file dialogs (a truly horrible design if there ever was one).
Monday, April 30, 2007
Open Source and the Enterprise
Here's an interesting question - is commercialization killing Open Source?. Personally, I don't believe commercialization is killing it, but it certainly has done plenty of damage. Free software OS's are thought of as products with free labor by profit-driven outfits, which is why, I think, FOSS (Free & Open Source Software) all of a sudden became so popular. The FOSS programmer on the other hand usually thinks of free software as a tool to scratch an itch.
This commercialization of free software might be why many forums, including popular ones like Slashdot, has been overrun by people who only see the business angle of FOSS (yuppies, I call them) and loudly protest any concept or idea that might present problems to businesses that capitalize on FOSS.
This commercialization of free software might be why many forums, including popular ones like Slashdot, has been overrun by people who only see the business angle of FOSS (yuppies, I call them) and loudly protest any concept or idea that might present problems to businesses that capitalize on FOSS.
Subscribe to:
Posts (Atom)