Yes, but I'm a mature adult and a professional. I'm not going to "hide" just on the off chance that some nutter is going to take exception to something--that's their problem, not mine. You don't see Larry Wall, Guido van Rossum or anyone else vaguely serious hiding behind a pseudonym for this reason. I've used my real name from the start as a free software developer, Debian developer, and professional scientist and professional software developer; I've also been involved in some heated discussions in my more youthful days, but that's never been escalated into anything outside being flamed by someone. There's a tradeoff here, and I don't think being anonymous/pseudoanonymous is sufficiently beneficial to warrant it; there's a certain loss of trust in doing so, and it hasn't been a problem for me in the last 18 years of free software- and software development-related activity. I don't think it's realistically possible to reconcile being a professional without being completely transparent as to your identity.
You're right that maybe different accounts are in order for different things. I certainly use separate accounts for "work", "free software development" and "personal" stuff, though I use my real identity for all of them in any case. Though in practice the latter two are somewhat blurred--I don't do much "personal" stuff online anyway--it's pretty much restricted to software-related stuff with personal things being primarily offline "real life" activities.
I always use my real full name. My slashdot account is an exception now (it was my email address back in '97) but my email is real. I don't see the benefit of total anonymity--as a free software developer both as a hobbyist and professional programmer, I don't want to participate in development behind some random handle, I want people to know who they are interacting with both in real life and via email/usenet/forums/bugtrackers/whatever. And vice versa Hiding behind anonymous handles is the exception rather than the rule, and while there are sometimes reasons for it, it's unusual. For whatever subconcious reason, I also tend to prefer to know who I'm dealing with--I'd be more likely to ignore or postpone dealing with a bug report from an anonymous person, for example. For some random unimportant forum it might not matter, but when you're participating in development with others over an extended period (years to decades) it would be a bit weird to be anonymous. While I think "doxxing" sounds like childish bullying, I don't see that hiding my name would help much should someone single me out. If they cared enough, they'd find out anyway.
That said, while my name and email addresses are not kept secret, I do value the privacy of my actual personal details etc., and I wouldn't be amused if they were published, but as mentioned in this discussion, stuff like phone numbers and addresses are "public" if you know where to look. Mine is in the paper phone book and you can look it up online. While it would be nice if idiots didn't abuse this, it's not realistic to keep secret stuff we need to communicate with each other. If you do a google image search for my name, three of the first two rows of images are me; two take you to my work profile page and my work contact details (email, phone, address), the other is my github profile. It would probably only take a few more minutes to work out my home address as well for a determined person. Occasionally I do get people contacting my via all these work details for legitimate purposes. While it would be nice to not have idiots abusing these things, we equally can't wall ourselves off from the world in an isolated bubble.
You know, the first idea isn't such a bad one! More seriously, he has the capital to drive any software development programme of his choice. He could be the next Mark Shuttleworth if he desired it.
If I had the capital, I'd likely set up a small company to do software development that interested me, and which would also be either useful to others (purely philanthropic) or would have some commercial demand too. The kind of stuff I want to do now but either can't devote time to, doing small bits and pieces here and there, or that requires more people than just me. So long as he has some goal to focus on, he can do whatever he wants. And as other posts mentioned, what he's lacking looks like a purpose in life--any purpose is better than wasting the opportunity the wealth brought him. Hell, he could buy many smaller corporations, start/join charities, anything he desired.
For acroymns, it does depends on the context. You couldn't pronounce IBM, CIA, NSA, GCHQ, HTML, XML, SMTP, FTP, etc. as words. "su" is a little ambiguous, "sue" being open to misinterpretation vs. "ess you".
WRT SEQUEL, I'm unaware of any newer ones, but SQL to my mind can only be pronounced "sequel" with a lot of imagination.
Regarding alternatives, I looked at Linux distribution alternatives but the choices are not great. I don't want the hassle of dealing with gentoo, though I'm sure it's fine. The others are all smaller projects which are largely dependent upon others. But longer-term, with the merging to udev and systemd and the merging of systemd-specific stuff into util-linux makes the long-term viability of any non-systemd distribution questionable. Short-term it's possible to avoid. But, there's a practical limit to how much individuals can do in the face of a huge juggernaught. eudev, vdev etc. are great but compatibility is always going to be an issue--they will have to play continual catchup. I decided to quit Linux entirely. FreeBSD was an obvious choice for a functional system, though OpenBSD and others would have likely been fine as well.
I'm on the dng mailing list. RSI prevents me from getting deeply involved at present--I've been unable to do much over the last 18 months, though I am slowly recovering. My thoughts are that I would be happy for it to succeed and wish it all the best, but as to its chances of success--I'll wait until there is a concrete release and they are set up for people to easily join and contribute before making any judgement. Setting up all the infrastructure from scratch is a difficult and expensive undertaking, and Debian is a huge project to clone and maintain which will take a serious number of people.
I think that while I might have phrased this a bit differently, this is certainly something which has changed. When I was a Debian developer, I was always the upstream developer of the code I packaged, or a contributor to the upstream codebase. i.e. I was familiar with and could make changes to the codebase as required, including custom patching for Debian when required. In recent years with package collections like the GNOME desktop, you did see big pushback from the Debian maintainers about making *any* changes to the upstream code. Any design problems or stupidites *had* to be accepted as they were. No patching or criticising. And I think this did in part stem from the "packagers" not being "developers", and I think this is a problem. We see the same thing with the systemd maintainers, and the message is that we are no longer independent developers but passive downstream consumers who must suck it up and deal with it. No thanks. It's that loss of independence that's the real killer. It turns every distribution into a clone of Fedora, and Fedora has never been a bastion of quality or reliability.
So it's kind of like jexec to run a command in a BSD jail, but for a container? Why not call it something short and sweet like "cexec" or "mexec" (for container, or machine if they insist on using "machine" in such as wierd way). If I'm typing commands all day long, I don't want each one to be an essay--I already have RSI.
SQL and SU are acronyms, and IME are always pronounced as such (separatetely); I've encountered "su" said as a word once only. DEL and REM are abbreviated forms of longer words (delete and remark), so are fine to pronounce as real words. "SEQUEL" is one that really grates, because it's always used in ignorance by people (usually MS SQL Server people) who are unaware that SEQUEL is actually an entirely different query language from SQL and that what they are saying is therefore ambiguous and incorrect.
The main thing I noticed with Ubuntu 15.04 at work is that rather than startup becoming faster and more deterministic as claimed, it's actually slower and randomly fails due to what looks like some race condition, requiring me to reset the machine. So the general experience is "meh", plus annoyance that it's actually degraded the reliability of booting.
I also suffered from the "we won't allow you to boot if your fstab contains an unmountable filesystem". So I reformatted an ext4 filesystem as NTFS to accomplish some work task on Windows; this really shouldn't be a reason to refuse to start up. I know the justification for doing this, and I think it's as bogus as the first time I saw it. I want my systems to boot, not hang up on a technicality because the configuration or system wasn't "perfect". i.e. a bit of realism and pragmatism rather than absolutionist perfectionism--like we used to have when people like me wrote the init scripts.
I can't speak for any distribution, after quitting as a Debian developer some months back, for several reasons one of which was systemd. But speaking for myself, it was quite clear during the several years of "debate" (i.e. flamewars) over systemd that this was the inevitable outcome. The debate over replacing the "init system" was a complete red herring; systemd knows no boundaries and continues to expand its tentacles over the system as it subsumes more and more components. My problem with this is that once a distribution has adopted systemd, they have to basically just accept whatever crap is shovelled out in the subsequent systemd releases--it's all or nothing and once you're on the train you can't get off it. This was absolutely obvious years ago. Quality software engineering and a solid base system walked out of the door when systemd arrived; I certainly did.
When I commit to a system such as a Linux distribution like Debian, I'm making an investment of my time and effort to use it. I do want to be able to rely on future releases being sane and not too radical a departure from previous releases--I am after all basing my work and livelihood upon it. With systemd, I don't know what I'm going to get with future versions and being able to rely on the distribution being usable and reliable in the future is now an unknown. That's why I got off this particular train before the jessie release. After 18 years, that wasn't an easy decision to make, but I still think it was the right one. And yes, I'm one of the people who moved to FreeBSD. Not because I wanted to move from Debian after having invested so much into it personally, but because I was forced to by this stupidity. And FreeBSD is a good solid dose of sanity.
This may be the case, and the experiences of Phoronix are certainly "higher profile" than the rest of us. However, the reality is that it's been awful in all the stable kernel releases as well. Maybe not this bug, but unbalancing and occasional dataloss have been a common experience for many people, including myself.
Nonsense. Btrfs is still not reliable. I've lost data from it twice when it trashed the filesystem irrecoverably, and more recently I've been suffering from the need to periodically rebalance. Where periodically is "approximately every 36 hours" under high load. I'm afraid that a filesystem which randomly stops working every 1.5 days because it used up all the free space (despite the disk being under 10% full) is most emphatically *not* production ready by any stretch of the imagination. Even FAT was more reliable than this. The bugs causing dataloss may have been resolved now, but the unbalancing is not and is a major blocker--how can you rely on a filesystem which can stop working unpredictably. You can't by definition.
ZFS on the other hand *is* production ready, and has been in production for years on serious hardware.
The poor state of Linux filesystems is what drove me to ZFS on Linux, and later migrate the pools to a FreeBSD fileserver--as simple as transferring the disks and importing the pool. Btrfs has been "almost ready" for years but has never yet reached the point where it's genuinely guaranteed reliable. I think the distributions which hopped onto the Btrfs bandwagon are fools, and their users will be the ones to suffer.
I'm afraid not. On FreeBSD itself, I only have jails at the moment. I did give VirtualBox a brief try, IIRC.
I have FreeBSD guests on a work VMware ESX cluster, and on VirtualBox and VMware Workstation on my personal development machine (Linux and Windows). At home, I have the same (VirtualBox and VMware Workstation on Linux and Windows).
RedHat has certainly made a lot of valuable contributions, particularly to the kernel and toolchain.
Their influence on GNOME and GTK+ is a bit more debateable. Do you remember what they were like in the 0.9/1.x days? They had participation from a wide range of companies and volunteers, and even if it was riddled with bugs it had the prospect of being something pretty amazing. Today, many of the original design flaws remain and many have had a lot of polishing, but the vibrant atmosphere and sense of progress have been lost. What it's lost is difficult to define precisely, but I think a large part of it is that it's lost perspective--when a project has a lot of people with different ideas all pulling it in different directions, it leads to a more rounded result whereas with only limited ideas, it ends up being insular on an inward-spiralling trajectory.
I don't think that the long-term health of these projects is good, and I think RedHat's management of the developers it put into place on these projects has not been ideal. While it serves their purpose to have control over the direction of these projects, it stifles any long-term viability when any non-RedHat-aligned suggestions or contributions are rejected. And with RedHat taking over an increasingly large number of basic Linux packages, and of course systemd, it leads to stagnation. And it's contrary to what made Linux great in the first place, and not just another commercial Unix.
I did my first Linux installs in 1997 (slack/redhat), and first Debian install in early 2008. I used Debian as my primary OS from 2009-2015 initially as a user and after a few years as a fully-fledged developer. I started investigating options for moving away from Debian around the end of 2013-early 2014, and migrated all my local data to a FreeBSD NAS in Jan 2014. As I learned more about it, the more I liked it. While it's fair to say that systemd was the primary impetus for looking for a replacement, it was not the main reason for switching. ZFS was the killer feature for the NAS. clang++ was a later reason to start using it for development. Today, I have FreeBSD on my main desktop, and in multiple VMs in addition to the NAS system. Oh, and Debian kFreeBSD in a jail on the NAS along with a bunch of other dedicated jails for development, PostgreSQL, and other tasks. When it comes to having a UNIX system that I want to use and hack on, FreeBSD is now closer to my ideal than where RedHat and Debian have gone. In some ways it feels kind of like Debian did back in the late 90s/early 2000s, and I mean that in a good way.
One of my workmates is also a long-time Debian user. A few weeks back, he got his first OpenBSD install and is also looking at his options for the future. His reasons: systemd and jessie, and he was very enthusiastic in how pleased he was with the OpenBSD install, and how he expected it to be more difficult to install and less featureful than he found it.
I think what's really changed is our attitude to Linux. It got pushed into workplaces and adopted because of the grass-roots advocacy and effort of developers, sysadmins and users worldwide. We cared deeply about it and weren't just users, we were active participants in its development. With the corporatisation of Linux, particularly by RedHat, I find I really no longer care about it, and this is primarily because I am no longer directly engaged in its development after being completely disenfranchised by corporate interests. When it comes to supporting it for work it's now kind of like having to support Windows--it's a requirement of the job and it will be done, but it's nothing to be passionate about, just a necessary part of the job. And I think that indifference will be more harmful to Linux than anything else. Linux came more from volunteer effort than any corporate contribution, and I think that's been forgotten by the companies involved... to their detriment.
Just finished upgrading all my work and home systems and VMs, plus one clean install. Smooth painless upgrades from 10.1-RELEASE and no problems encountered, all systems running nicely. Great work, team, your efforts are much appreciated.
FreeBSD merrilin.codelibre.net 10.2-RELEASE FreeBSD 10.2-RELEASE #0 r286666: Wed Aug 12 15:26:37 UTC 2015 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64
SPARC certainly, and the same previously applied to alpha and hppa (and m68k). So long as the kernel and toolchain are well supported, porting isn't too onerous. But once the kernel and/or toolchain become flaky, it's dicey for development and end use. I used to be quite involved in powerpc porting (I got a G4 mac mini to run Debian powerpc, which was my primary development system for around five years). I quit doing powerpc work a couple of years back when the system was too slow for practical work compared with contemporary hardware.
The main factor in a port's viability is an active developer pool contributing time to maintain it, and a port which is sustained only by dedicated people with obsolete hardware is doomed to eventual failure--the hardware pool is restricted and the number of developers is even less, so it's an inevitable case of attrition. When Sun stopped selling SPARC hardware at the lower end--where individual developers could afford them--its fate was sealed. The same thing also applies to powerpc to a lesser extent--most developers such as myself got powerpc hardware from Apple as a cheap way to get a big endian platform. When Apple dropped powerpc, there was little else to fill the gap. While I would love an IBM OpenPOWER system, the reality is that it's too expensive to justify and unless you get a genuine pool of developers bought into it, it's not going to have decent support. But take a non-x86 platform like ARM, that's still genuinely viable and will be for the foreseeable future.
Regarding the systemd comment, while I think the practical reality of hardware availability and obsolescence are the primary factor here, I do think it does have a small part to play. Consider that support for all these less common architectures was integrated into Debian over many years, and that some of this support comes in the form of special-cases in all sorts of init scripts and other support files. It's inevitable that some parts of this support for non-x86 architectures will regress with systemd unless it's specifically ported to the systemd equivalents (if possible).
As for me, let's just say my powerpc system is now running FreeBSD.
People with PhDs move into very different fields all the time. Nowadays people with PhDs in any scientific or engineering discipline have likely had to do a lot of computational work, and that likely involved exposure to Unix/Linux, often to a significant degree. I know people from maths, chemistry, physics, engineering and biology backgrounds who have all moved to software engineering. I myself have a PhD in immunology and cell biology, yet I'm a full time software developer working on image processing with C, C++, Python, Java, R and OpenGL (mainly C++ at the moment, though I use all the languages to some degree all the time), and I was a Debian developer for over a decade. If you went around my old Biology department, you would find a large number of people working full time in C++, Java, Python, R, Matlab, and many other languages and tools, doing some pretty advanced stuff from complex simulations from the atomic to tissue and organism scale, to complex modelling of protein structures and molecular interactions, to advanced image visualisation and processing. Even a perceived to be simpler area such as ecology is heavily based around incredibly complex statistics. At the university I currently work at, I'm based in a big life sciences department which contains not one, but several teams of software developers working in wildly different areas, from many varied backgrounds, and this also applies to many companies who gain much from having a diverse team with very different experience and skills.
Re: Try Stack Overflow and --synclines
on
GCC 5.2 Released
·
· Score: 2
As another poster commented, it's another tool to install, which is a burden. And if you use a newer version, it makes it harder to build the package on older distributions; though as you can see at the top of my example, you can specify a minimum cmake version and also through its policy mechanism general behaviour matching a specific version with tweaks for individual policies, so it's certainly possible to be backward compatible if you make the effort, at the expense of not using newer-version-only features.
The inertia is certainly real, and understandable. Many people have decades of practice with the autotools, and that's a hard-gained investment to drop. I'd been using it since 1999 and and later did the GNU Autoconf copyright assignment, and contributed the C99 and C++11 support macros. That said, I took a week out and learned CMake, converting my most autotools-heavy project to CMake in about a week. Now I understand it, it's much quicker. bzip2 took a few hours; libtiff a few days--after a few rounds of review and making it work on Windows. KDE did the migration years ago--searching for the rationale behind this brings up some interesting material. For an average project, the barrier is primarily in the mind; the one-time cost of conversion is not really that high even for a project with dozens of feature tests and custom macros.
The primary motivation for me was accessibility to project developers and external contributors. The Autotools are impenetrable to the non-initiated, and have a somewhat high maintenance burden when it comes to refactoring. CMake is a single, very well documented, tool. You can make simple modifications with little or no experience, and for any parts you don't understand, there are the manual pages which explain what each variable, command, macro and function does. And for any place I found it lacking, I've submitted patches upstream which have been merged within days (typically under 24 hours); they are extremely helpful and responsive on IRC and their mailing lists, and there is a good community of third-party submissions handling all sorts of integration and portability issues.
The other motivation was portability. The Autotools restrict themselves to POSIX systems, but many free software and commercial projects also have a requirement to run on Windows. Many of these provide both Autotools and Visual Studio project files (one set per version in some cases). This maintenance nightmare can be replaced entirely with CMake. For example, the BSD and GPL code I work on for my day job is primarily developed on Linux (tested on Debian, Ubuntu, CentOS and FreeBSD) but also needs to run on MacOS X and Windows. After evaluating all the different build systems, only CMake really solved the problem. Even GNU software is often used on Windows, and so could benefit from this, despite potential ideological objections. Also, it's easy with the Autotools to tie yourself to requiring GNU make; CMake generates Makefiles which work with BSD make but can use some GNU features if present, so it also solves some BSD portability issues at the same time.
Re: Try Stack Overflow and --synclines
on
GCC 5.2 Released
·
· Score: 1
Hi Bruce,
As an example, take a look at the script for libtiff, lines 180-402 in particular since these are copying exactly what the original configure script does. The rest is also copying the configure script (options, etc.), but this section is the feature tests.
Re: Try Stack Overflow and --synclines
on
GCC 5.2 Released
·
· Score: 4, Informative
You can think of CMake as autoheader, autoconf, automake and libtool rolled up into one tool. It's a scripting language which is evaluated, the end products being generated files of any type you like, plus the files for a specified build system, typically Makefiles on UNIX, but could be many other types. It's a superset of the functionality of the autotools, and is vastly more maintainable and flexible, not to mention portable to non-POSIX platforms. It's not the nicest language I've encountered, but it's certainly better than the multi-language mess of m4/shell/templates we live with in the Autoconf world.
You can do all the feature testing with CMake that you can with Autoconf. For example, in place of AC_TRY_COMPILE, you use CHECK_C_SOURCE_COMPILES, or the equivalent in another language. There are variants for all sorts of other feature tests and checks, same as with Autoconf. But in general, I think it solves current portability problems somewhat better and more portably that the Autotools, which seem to still be stuck in the 90s in terms of the problems they try to solve. Example: portably enabling threading.
When creating custom headers for macros from the feature test results, in place of AC_CONFIG_HEADER you would use configure_file, which does exactly the same thing using CMake variables.
After 15 years of autotools usage, I converted my most important projects to CMake around 22 months ago, and haven't looked back. Most recently, I did conversions from autotools for bzip2 and libtiff. In both cases, the conversion is pretty much a 1:1 change from Autoconf macro or Automake variable to the corresponding CMake macro/function/variable.
You seem to be in violent agreement with what I said. Both weak_ptr and WeakReference are a means of holding a reference to an object which may be collected when the last strong reference is lost; in both cases the weak references do not prevent collection. Both may be used for caches, as well as other purposes. Not sure why you felt the need to debate this further--it doesn't seem of any particular interest outside some uninteresting minor differences.
The burden of where to delete can be quite high, and in some cases intractable. It's easy in the simple case. But as soon as you start having to consider (in the context of allocation lifetime in a function or method) multiple return points and exceptions, this can become very difficult, without even considering thread safety. RAII means all these cases are handled by the language's destruction of smartptr instances on scope exit. Once you add multiple pointers with the same or differing lifetimes in nested scopes into the mix, the burden becomes even worse. This could be as simple as a continue statement in a for loop. All the try/catch blocks for every thrown exception and special cleanup for each return point add up to a huge amount of effort expended to do something which the compiler can do totally reliably, and with much more readable code. You only have to forget to handle one single exception and you have a leak. And outside the scope of a function where you need to consider ownership, ownership transfer, sharing and lifetime, there's a whole set of additional problems layered on top of what was already becoming a bit of a nightmare. And when you consider bugs introduced by future changes and refactoring, the maintenance burden and risk are vastly increased as well.
Not sure where your comment about Java programmers came from; it certainly wasn't from me.
I'm certainly intimately familiar with how new and delete work and how to use them. Even with that knowledge and understanding, I choose to not use them except in extremely special circumstances. My choosing not to use them is in large part *because* I understand them. Back in the '90s, use of new and delete was commonplace, but their poor interaction with exceptions and threads pre-standardisation wasn't yet completely understood, and solutions for how to handle this properly hadn't been fully developed, and this made for spectacular problems. We discovered RAII as the answer. auto_ptr (C++98) and then shared_ptr (Boost, TR1 and C++11) and now unique_ptr (C++11) are the result of our evolving understanding of how to do things correctly and robustly. The general consensus has shifted over the years strongly in favour of using smartpointers. If you read a few current books on recommended modern practice, you'll see this, and their official presence in the ISO C++11 standard library reflects this. They are *not* new; shared_ptr dates back to around 2001; I've been using it in production code since 2005.
Ultimately it comes down to this: why do manually what can be simply and reliably automated? This is what we use computers for in the first place; not applying this logic to your own code seems illogical. What gain do you have doing things the "hard way" for little in return? The cost:benefit of using bare pointers over smart pointers is low.
You're correct that this does lower the bar for beginners, and this is a good thing. It does make some parts of using C++ simpler. But this certainly doesn't mean it's not appropriate for experts to use as well. Real experts will know the reasons for using them. And you don't need to be using C++11 or 14 to take advantage of them; shared_ptr has been around in Boost for nearly 15 years. If you're a professional C++ programmer, keeping up to date and informed about this stuff is essential.
Slashdot Mirror
nVidia do provide a FreeBSD driver. (I wish AMD did the same, since the xorg drivers are currently not supporting the latest cards.)
Yes, but I'm a mature adult and a professional. I'm not going to "hide" just on the off chance that some nutter is going to take exception to something--that's their problem, not mine. You don't see Larry Wall, Guido van Rossum or anyone else vaguely serious hiding behind a pseudonym for this reason. I've used my real name from the start as a free software developer, Debian developer, and professional scientist and professional software developer; I've also been involved in some heated discussions in my more youthful days, but that's never been escalated into anything outside being flamed by someone. There's a tradeoff here, and I don't think being anonymous/pseudoanonymous is sufficiently beneficial to warrant it; there's a certain loss of trust in doing so, and it hasn't been a problem for me in the last 18 years of free software- and software development-related activity. I don't think it's realistically possible to reconcile being a professional without being completely transparent as to your identity.
You're right that maybe different accounts are in order for different things. I certainly use separate accounts for "work", "free software development" and "personal" stuff, though I use my real identity for all of them in any case. Though in practice the latter two are somewhat blurred--I don't do much "personal" stuff online anyway--it's pretty much restricted to software-related stuff with personal things being primarily offline "real life" activities.
Serious question. Why?
I always use my real full name. My slashdot account is an exception now (it was my email address back in '97) but my email is real. I don't see the benefit of total anonymity--as a free software developer both as a hobbyist and professional programmer, I don't want to participate in development behind some random handle, I want people to know who they are interacting with both in real life and via email/usenet/forums/bugtrackers/whatever. And vice versa Hiding behind anonymous handles is the exception rather than the rule, and while there are sometimes reasons for it, it's unusual. For whatever subconcious reason, I also tend to prefer to know who I'm dealing with--I'd be more likely to ignore or postpone dealing with a bug report from an anonymous person, for example. For some random unimportant forum it might not matter, but when you're participating in development with others over an extended period (years to decades) it would be a bit weird to be anonymous. While I think "doxxing" sounds like childish bullying, I don't see that hiding my name would help much should someone single me out. If they cared enough, they'd find out anyway.
That said, while my name and email addresses are not kept secret, I do value the privacy of my actual personal details etc., and I wouldn't be amused if they were published, but as mentioned in this discussion, stuff like phone numbers and addresses are "public" if you know where to look. Mine is in the paper phone book and you can look it up online. While it would be nice if idiots didn't abuse this, it's not realistic to keep secret stuff we need to communicate with each other. If you do a google image search for my name, three of the first two rows of images are me; two take you to my work profile page and my work contact details (email, phone, address), the other is my github profile. It would probably only take a few more minutes to work out my home address as well for a determined person. Occasionally I do get people contacting my via all these work details for legitimate purposes. While it would be nice to not have idiots abusing these things, we equally can't wall ourselves off from the world in an isolated bubble.
Regards,
Roger
You know, the first idea isn't such a bad one! More seriously, he has the capital to drive any software development programme of his choice. He could be the next Mark Shuttleworth if he desired it.
If I had the capital, I'd likely set up a small company to do software development that interested me, and which would also be either useful to others (purely philanthropic) or would have some commercial demand too. The kind of stuff I want to do now but either can't devote time to, doing small bits and pieces here and there, or that requires more people than just me. So long as he has some goal to focus on, he can do whatever he wants. And as other posts mentioned, what he's lacking looks like a purpose in life--any purpose is better than wasting the opportunity the wealth brought him. Hell, he could buy many smaller corporations, start/join charities, anything he desired.
For acroymns, it does depends on the context. You couldn't pronounce IBM, CIA, NSA, GCHQ, HTML, XML, SMTP, FTP, etc. as words. "su" is a little ambiguous, "sue" being open to misinterpretation vs. "ess you".
WRT SEQUEL, I'm unaware of any newer ones, but SQL to my mind can only be pronounced "sequel" with a lot of imagination.
Regarding alternatives, I looked at Linux distribution alternatives but the choices are not great. I don't want the hassle of dealing with gentoo, though I'm sure it's fine. The others are all smaller projects which are largely dependent upon others. But longer-term, with the merging to udev and systemd and the merging of systemd-specific stuff into util-linux makes the long-term viability of any non-systemd distribution questionable. Short-term it's possible to avoid. But, there's a practical limit to how much individuals can do in the face of a huge juggernaught. eudev, vdev etc. are great but compatibility is always going to be an issue--they will have to play continual catchup. I decided to quit Linux entirely. FreeBSD was an obvious choice for a functional system, though OpenBSD and others would have likely been fine as well.
I'm on the dng mailing list. RSI prevents me from getting deeply involved at present--I've been unable to do much over the last 18 months, though I am slowly recovering. My thoughts are that I would be happy for it to succeed and wish it all the best, but as to its chances of success--I'll wait until there is a concrete release and they are set up for people to easily join and contribute before making any judgement. Setting up all the infrastructure from scratch is a difficult and expensive undertaking, and Debian is a huge project to clone and maintain which will take a serious number of people.
I think that while I might have phrased this a bit differently, this is certainly something which has changed. When I was a Debian developer, I was always the upstream developer of the code I packaged, or a contributor to the upstream codebase. i.e. I was familiar with and could make changes to the codebase as required, including custom patching for Debian when required. In recent years with package collections like the GNOME desktop, you did see big pushback from the Debian maintainers about making *any* changes to the upstream code. Any design problems or stupidites *had* to be accepted as they were. No patching or criticising. And I think this did in part stem from the "packagers" not being "developers", and I think this is a problem. We see the same thing with the systemd maintainers, and the message is that we are no longer independent developers but passive downstream consumers who must suck it up and deal with it. No thanks. It's that loss of independence that's the real killer. It turns every distribution into a clone of Fedora, and Fedora has never been a bastion of quality or reliability.
So it's kind of like jexec to run a command in a BSD jail, but for a container? Why not call it something short and sweet like "cexec" or "mexec" (for container, or machine if they insist on using "machine" in such as wierd way). If I'm typing commands all day long, I don't want each one to be an essay--I already have RSI.
SQL and SU are acronyms, and IME are always pronounced as such (separatetely); I've encountered "su" said as a word once only. DEL and REM are abbreviated forms of longer words (delete and remark), so are fine to pronounce as real words. "SEQUEL" is one that really grates, because it's always used in ignorance by people (usually MS SQL Server people) who are unaware that SEQUEL is actually an entirely different query language from SQL and that what they are saying is therefore ambiguous and incorrect.
The main thing I noticed with Ubuntu 15.04 at work is that rather than startup becoming faster and more deterministic as claimed, it's actually slower and randomly fails due to what looks like some race condition, requiring me to reset the machine. So the general experience is "meh", plus annoyance that it's actually degraded the reliability of booting.
I also suffered from the "we won't allow you to boot if your fstab contains an unmountable filesystem". So I reformatted an ext4 filesystem as NTFS to accomplish some work task on Windows; this really shouldn't be a reason to refuse to start up. I know the justification for doing this, and I think it's as bogus as the first time I saw it. I want my systems to boot, not hang up on a technicality because the configuration or system wasn't "perfect". i.e. a bit of realism and pragmatism rather than absolutionist perfectionism--like we used to have when people like me wrote the init scripts.
I can't speak for any distribution, after quitting as a Debian developer some months back, for several reasons one of which was systemd. But speaking for myself, it was quite clear during the several years of "debate" (i.e. flamewars) over systemd that this was the inevitable outcome. The debate over replacing the "init system" was a complete red herring; systemd knows no boundaries and continues to expand its tentacles over the system as it subsumes more and more components. My problem with this is that once a distribution has adopted systemd, they have to basically just accept whatever crap is shovelled out in the subsequent systemd releases--it's all or nothing and once you're on the train you can't get off it. This was absolutely obvious years ago. Quality software engineering and a solid base system walked out of the door when systemd arrived; I certainly did.
When I commit to a system such as a Linux distribution like Debian, I'm making an investment of my time and effort to use it. I do want to be able to rely on future releases being sane and not too radical a departure from previous releases--I am after all basing my work and livelihood upon it. With systemd, I don't know what I'm going to get with future versions and being able to rely on the distribution being usable and reliable in the future is now an unknown. That's why I got off this particular train before the jessie release. After 18 years, that wasn't an easy decision to make, but I still think it was the right one. And yes, I'm one of the people who moved to FreeBSD. Not because I wanted to move from Debian after having invested so much into it personally, but because I was forced to by this stupidity. And FreeBSD is a good solid dose of sanity.
This may be the case, and the experiences of Phoronix are certainly "higher profile" than the rest of us. However, the reality is that it's been awful in all the stable kernel releases as well. Maybe not this bug, but unbalancing and occasional dataloss have been a common experience for many people, including myself.
Nonsense. Btrfs is still not reliable. I've lost data from it twice when it trashed the filesystem irrecoverably, and more recently I've been suffering from the need to periodically rebalance. Where periodically is "approximately every 36 hours" under high load. I'm afraid that a filesystem which randomly stops working every 1.5 days because it used up all the free space (despite the disk being under 10% full) is most emphatically *not* production ready by any stretch of the imagination. Even FAT was more reliable than this. The bugs causing dataloss may have been resolved now, but the unbalancing is not and is a major blocker--how can you rely on a filesystem which can stop working unpredictably. You can't by definition.
ZFS on the other hand *is* production ready, and has been in production for years on serious hardware.
The poor state of Linux filesystems is what drove me to ZFS on Linux, and later migrate the pools to a FreeBSD fileserver--as simple as transferring the disks and importing the pool. Btrfs has been "almost ready" for years but has never yet reached the point where it's genuinely guaranteed reliable. I think the distributions which hopped onto the Btrfs bandwagon are fools, and their users will be the ones to suffer.
I'm afraid not. On FreeBSD itself, I only have jails at the moment. I did give VirtualBox a brief try, IIRC.
I have FreeBSD guests on a work VMware ESX cluster, and on VirtualBox and VMware Workstation on my personal development machine (Linux and Windows). At home, I have the same (VirtualBox and VMware Workstation on Linux and Windows).
RedHat has certainly made a lot of valuable contributions, particularly to the kernel and toolchain.
Their influence on GNOME and GTK+ is a bit more debateable. Do you remember what they were like in the 0.9/1.x days? They had participation from a wide range of companies and volunteers, and even if it was riddled with bugs it had the prospect of being something pretty amazing. Today, many of the original design flaws remain and many have had a lot of polishing, but the vibrant atmosphere and sense of progress have been lost. What it's lost is difficult to define precisely, but I think a large part of it is that it's lost perspective--when a project has a lot of people with different ideas all pulling it in different directions, it leads to a more rounded result whereas with only limited ideas, it ends up being insular on an inward-spiralling trajectory.
I don't think that the long-term health of these projects is good, and I think RedHat's management of the developers it put into place on these projects has not been ideal. While it serves their purpose to have control over the direction of these projects, it stifles any long-term viability when any non-RedHat-aligned suggestions or contributions are rejected. And with RedHat taking over an increasingly large number of basic Linux packages, and of course systemd, it leads to stagnation. And it's contrary to what made Linux great in the first place, and not just another commercial Unix.
I did my first Linux installs in 1997 (slack/redhat), and first Debian install in early 2008. I used Debian as my primary OS from 2009-2015 initially as a user and after a few years as a fully-fledged developer. I started investigating options for moving away from Debian around the end of 2013-early 2014, and migrated all my local data to a FreeBSD NAS in Jan 2014. As I learned more about it, the more I liked it. While it's fair to say that systemd was the primary impetus for looking for a replacement, it was not the main reason for switching. ZFS was the killer feature for the NAS. clang++ was a later reason to start using it for development. Today, I have FreeBSD on my main desktop, and in multiple VMs in addition to the NAS system. Oh, and Debian kFreeBSD in a jail on the NAS along with a bunch of other dedicated jails for development, PostgreSQL, and other tasks. When it comes to having a UNIX system that I want to use and hack on, FreeBSD is now closer to my ideal than where RedHat and Debian have gone. In some ways it feels kind of like Debian did back in the late 90s/early 2000s, and I mean that in a good way.
One of my workmates is also a long-time Debian user. A few weeks back, he got his first OpenBSD install and is also looking at his options for the future. His reasons: systemd and jessie, and he was very enthusiastic in how pleased he was with the OpenBSD install, and how he expected it to be more difficult to install and less featureful than he found it.
I think what's really changed is our attitude to Linux. It got pushed into workplaces and adopted because of the grass-roots advocacy and effort of developers, sysadmins and users worldwide. We cared deeply about it and weren't just users, we were active participants in its development. With the corporatisation of Linux, particularly by RedHat, I find I really no longer care about it, and this is primarily because I am no longer directly engaged in its development after being completely disenfranchised by corporate interests. When it comes to supporting it for work it's now kind of like having to support Windows--it's a requirement of the job and it will be done, but it's nothing to be passionate about, just a necessary part of the job. And I think that indifference will be more harmful to Linux than anything else. Linux came more from volunteer effort than any corporate contribution, and I think that's been forgotten by the companies involved... to their detriment.
When you say, "wait to become final", it is final now as far as I can tell. Can't you run:
freebsd-update -r 10.2-RELEASE upgrade
freebsd-update install
reboot
freebsd-update install
pkg update
pkg upgrade
That's pretty much what I did for all the systems I upgraded to 10.2.
Just finished upgrading all my work and home systems and VMs, plus one clean install. Smooth painless upgrades from 10.1-RELEASE and no problems encountered, all systems running nicely. Great work, team, your efforts are much appreciated.
FreeBSD merrilin.codelibre.net 10.2-RELEASE FreeBSD 10.2-RELEASE #0 r286666: Wed Aug 12 15:26:37 UTC 2015 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64
SPARC certainly, and the same previously applied to alpha and hppa (and m68k). So long as the kernel and toolchain are well supported, porting isn't too onerous. But once the kernel and/or toolchain become flaky, it's dicey for development and end use. I used to be quite involved in powerpc porting (I got a G4 mac mini to run Debian powerpc, which was my primary development system for around five years). I quit doing powerpc work a couple of years back when the system was too slow for practical work compared with contemporary hardware.
The main factor in a port's viability is an active developer pool contributing time to maintain it, and a port which is sustained only by dedicated people with obsolete hardware is doomed to eventual failure--the hardware pool is restricted and the number of developers is even less, so it's an inevitable case of attrition. When Sun stopped selling SPARC hardware at the lower end--where individual developers could afford them--its fate was sealed. The same thing also applies to powerpc to a lesser extent--most developers such as myself got powerpc hardware from Apple as a cheap way to get a big endian platform. When Apple dropped powerpc, there was little else to fill the gap. While I would love an IBM OpenPOWER system, the reality is that it's too expensive to justify and unless you get a genuine pool of developers bought into it, it's not going to have decent support. But take a non-x86 platform like ARM, that's still genuinely viable and will be for the foreseeable future.
Regarding the systemd comment, while I think the practical reality of hardware availability and obsolescence are the primary factor here, I do think it does have a small part to play. Consider that support for all these less common architectures was integrated into Debian over many years, and that some of this support comes in the form of special-cases in all sorts of init scripts and other support files. It's inevitable that some parts of this support for non-x86 architectures will regress with systemd unless it's specifically ported to the systemd equivalents (if possible).
As for me, let's just say my powerpc system is now running FreeBSD.
Why on earth would you think this?
People with PhDs move into very different fields all the time. Nowadays people with PhDs in any scientific or engineering discipline have likely had to do a lot of computational work, and that likely involved exposure to Unix/Linux, often to a significant degree. I know people from maths, chemistry, physics, engineering and biology backgrounds who have all moved to software engineering. I myself have a PhD in immunology and cell biology, yet I'm a full time software developer working on image processing with C, C++, Python, Java, R and OpenGL (mainly C++ at the moment, though I use all the languages to some degree all the time), and I was a Debian developer for over a decade. If you went around my old Biology department, you would find a large number of people working full time in C++, Java, Python, R, Matlab, and many other languages and tools, doing some pretty advanced stuff from complex simulations from the atomic to tissue and organism scale, to complex modelling of protein structures and molecular interactions, to advanced image visualisation and processing. Even a perceived to be simpler area such as ecology is heavily based around incredibly complex statistics. At the university I currently work at, I'm based in a big life sciences department which contains not one, but several teams of software developers working in wildly different areas, from many varied backgrounds, and this also applies to many companies who gain much from having a diverse team with very different experience and skills.
As another poster commented, it's another tool to install, which is a burden. And if you use a newer version, it makes it harder to build the package on older distributions; though as you can see at the top of my example, you can specify a minimum cmake version and also through its policy mechanism general behaviour matching a specific version with tweaks for individual policies, so it's certainly possible to be backward compatible if you make the effort, at the expense of not using newer-version-only features.
The inertia is certainly real, and understandable. Many people have decades of practice with the autotools, and that's a hard-gained investment to drop. I'd been using it since 1999 and and later did the GNU Autoconf copyright assignment, and contributed the C99 and C++11 support macros. That said, I took a week out and learned CMake, converting my most autotools-heavy project to CMake in about a week. Now I understand it, it's much quicker. bzip2 took a few hours; libtiff a few days--after a few rounds of review and making it work on Windows. KDE did the migration years ago--searching for the rationale behind this brings up some interesting material. For an average project, the barrier is primarily in the mind; the one-time cost of conversion is not really that high even for a project with dozens of feature tests and custom macros.
The primary motivation for me was accessibility to project developers and external contributors. The Autotools are impenetrable to the non-initiated, and have a somewhat high maintenance burden when it comes to refactoring. CMake is a single, very well documented, tool. You can make simple modifications with little or no experience, and for any parts you don't understand, there are the manual pages which explain what each variable, command, macro and function does. And for any place I found it lacking, I've submitted patches upstream which have been merged within days (typically under 24 hours); they are extremely helpful and responsive on IRC and their mailing lists, and there is a good community of third-party submissions handling all sorts of integration and portability issues.
The other motivation was portability. The Autotools restrict themselves to POSIX systems, but many free software and commercial projects also have a requirement to run on Windows. Many of these provide both Autotools and Visual Studio project files (one set per version in some cases). This maintenance nightmare can be replaced entirely with CMake. For example, the BSD and GPL code I work on for my day job is primarily developed on Linux (tested on Debian, Ubuntu, CentOS and FreeBSD) but also needs to run on MacOS X and Windows. After evaluating all the different build systems, only CMake really solved the problem. Even GNU software is often used on Windows, and so could benefit from this, despite potential ideological objections. Also, it's easy with the Autotools to tie yourself to requiring GNU make; CMake generates Makefiles which work with BSD make but can use some GNU features if present, so it also solves some BSD portability issues at the same time.
Hi Bruce,
As an example, take a look at the script for libtiff, lines 180-402 in particular since these are copying exactly what the original configure script does. The rest is also copying the configure script (options, etc.), but this section is the feature tests.
You can think of CMake as autoheader, autoconf, automake and libtool rolled up into one tool. It's a scripting language which is evaluated, the end products being generated files of any type you like, plus the files for a specified build system, typically Makefiles on UNIX, but could be many other types. It's a superset of the functionality of the autotools, and is vastly more maintainable and flexible, not to mention portable to non-POSIX platforms. It's not the nicest language I've encountered, but it's certainly better than the multi-language mess of m4/shell/templates we live with in the Autoconf world.
You can do all the feature testing with CMake that you can with Autoconf. For example, in place of AC_TRY_COMPILE, you use CHECK_C_SOURCE_COMPILES, or the equivalent in another language. There are variants for all sorts of other feature tests and checks, same as with Autoconf. But in general, I think it solves current portability problems somewhat better and more portably that the Autotools, which seem to still be stuck in the 90s in terms of the problems they try to solve. Example: portably enabling threading.
When creating custom headers for macros from the feature test results, in place of AC_CONFIG_HEADER you would use configure_file, which does exactly the same thing using CMake variables.
After 15 years of autotools usage, I converted my most important projects to CMake around 22 months ago, and haven't looked back. Most recently, I did conversions from autotools for bzip2 and libtiff. In both cases, the conversion is pretty much a 1:1 change from Autoconf macro or Automake variable to the corresponding CMake macro/function/variable.
Regards,
Roger
You seem to be in violent agreement with what I said. Both weak_ptr and WeakReference are a means of holding a reference to an object which may be collected when the last strong reference is lost; in both cases the weak references do not prevent collection. Both may be used for caches, as well as other purposes. Not sure why you felt the need to debate this further--it doesn't seem of any particular interest outside some uninteresting minor differences.
The burden of where to delete can be quite high, and in some cases intractable. It's easy in the simple case. But as soon as you start having to consider (in the context of allocation lifetime in a function or method) multiple return points and exceptions, this can become very difficult, without even considering thread safety. RAII means all these cases are handled by the language's destruction of smartptr instances on scope exit. Once you add multiple pointers with the same or differing lifetimes in nested scopes into the mix, the burden becomes even worse. This could be as simple as a continue statement in a for loop. All the try/catch blocks for every thrown exception and special cleanup for each return point add up to a huge amount of effort expended to do something which the compiler can do totally reliably, and with much more readable code. You only have to forget to handle one single exception and you have a leak. And outside the scope of a function where you need to consider ownership, ownership transfer, sharing and lifetime, there's a whole set of additional problems layered on top of what was already becoming a bit of a nightmare. And when you consider bugs introduced by future changes and refactoring, the maintenance burden and risk are vastly increased as well.
Not sure where your comment about Java programmers came from; it certainly wasn't from me.
I'm certainly intimately familiar with how new and delete work and how to use them. Even with that knowledge and understanding, I choose to not use them except in extremely special circumstances. My choosing not to use them is in large part *because* I understand them. Back in the '90s, use of new and delete was commonplace, but their poor interaction with exceptions and threads pre-standardisation wasn't yet completely understood, and solutions for how to handle this properly hadn't been fully developed, and this made for spectacular problems. We discovered RAII as the answer. auto_ptr (C++98) and then shared_ptr (Boost, TR1 and C++11) and now unique_ptr (C++11) are the result of our evolving understanding of how to do things correctly and robustly. The general consensus has shifted over the years strongly in favour of using smartpointers. If you read a few current books on recommended modern practice, you'll see this, and their official presence in the ISO C++11 standard library reflects this. They are *not* new; shared_ptr dates back to around 2001; I've been using it in production code since 2005.
Ultimately it comes down to this: why do manually what can be simply and reliably automated? This is what we use computers for in the first place; not applying this logic to your own code seems illogical. What gain do you have doing things the "hard way" for little in return? The cost:benefit of using bare pointers over smart pointers is low.
You're correct that this does lower the bar for beginners, and this is a good thing. It does make some parts of using C++ simpler. But this certainly doesn't mean it's not appropriate for experts to use as well. Real experts will know the reasons for using them. And you don't need to be using C++11 or 14 to take advantage of them; shared_ptr has been around in Boost for nearly 15 years. If you're a professional C++ programmer, keeping up to date and informed about this stuff is essential.