Slashdot Mirror

Yes, because the average user wants their desktop to break when they update their OS because their nvidia driver didn't compile correctly...

Ubuntu (and therefore everything based on it) has the http://ppa.launchpad.net/graph... repositories with the latest precompiled Nvidia drivers. Compiling an Nvidia driver hasn't been necessary in years. And Nvidia has really gotten its Linux act together recently, as their newer drivers integrate into the desktop seamlessly. This obviates all of the GCC stuff. There are legitimate problems, but having to manually compile anything isn't one of them.

My KDE desktop settings have mostly carried over for the last few rolling Kubuntu distribution upgrades. The sole exceptions have all been in the KDEPIN suite, which has gotten so bad that I stopped using every single application in the suite. It went from being a very respectable collection of integrated software to being an unpredictable, data-destroying nightmare that I can't stand anymore.

I have a small list of issues that I think would hold back the average person from being completely self-sufficient with Kubuntu, but none of them are show-stoppers.

They'd have to reopen Bug #1

Here's a bug report for the same issue (I think, at the bottom).

Additionally there was a period when the process scheduler was designed very poorly for interactivity around then and patches to make it selectable or more interactive were poo pooed.

Shortly after Linus spoke out strongly against spinning rust. It was pretty clear that was the use case being designed for wasn't me, both in experience and rhetoric.

Linux went from a decent solution for me in the late 90s early 2000s (still played some games on windows), to a great one and my only desktop in the mid to late 00s, then to unusable on my hardware for a while.

After a decade or so of rapid improvement in the desktop experience (under the hood and more in ones face) there was a multi year stint where both regressed.

I'm sure it's great again, but so is everything else from a desktop user perspective. I used cygwin and now Linux on Windows to fill the gaps Windows leaves me missing.

https://bugs.launchpad.net/ubu...

While the PHP 5->7 parade is a serious problem, this weird MS-ISAC advisory appears to be bogus. Most likely ineptitude. You know what they say about ineptitude and malice.

Here's a public note from Ubuntu's maintainer about it.
https://bugs.launchpad.net/ubuntu/+source/php7.2/+bug/1798625

How did this get all over the news without so much as a CVE attached to it? It certainly seems like a fake news hack job.

These are lists of bugs in just gnome-shell. The reading is terrifying for people who actually want to work with Ubuntu. Some were known before releasing 18.04 "LTS", are still not fixed, and force me to avoid using full-screen video and to reboot my Ubuntu VM very regularly. Luckily I don't depend on Ubuntu for work, it's just a VM...

https://trello.com/c/pe5mRmx7
https://bugs.launchpad.net/ubu...

ecryptfs was dropped from the Ubuntu installer and deprecated in 18.04 LTS in favor of full disk or manually using fscrypt (work is ongoing to make this easier) - because it does have various issues.

See this bug for more: https://bugs.launchpad.net/ubu...

How much of the open source code you use do you check?

Me? Well, there's this long discussion with the Lucky web platform developer the other day. And they just closed a bug I reported in Mailman. That sort of thing goes on all of the time.

"a ton of GREAT apps on Ubuntu are Electron apps" -- Mark Shuttleworth For sure, a new installer is the "top priority" issue of Ubuntu OS. https://bugs.launchpad.net/ubu... returns ONLY 137332 open bugs (434 critical)

Anyone who uses the stock Ubuntu AMIs on AWS EC2 knows that there is no "installation" -- you get a bootable and usable OS instantly.

So, will this feature be enabled by default in those AMIs? If so, how can one opt out of it as early on as possible so that nothing gets transmit to Canonical *ever*?

This distantly reminds me of the Canonical's choice to stick content of their choosing into your MOTD. I got wind of this because our Ubuntu-based systems in AWS suddenly had lines talking about irrelevant TV shows in our MOTDs. A ticket was filed to investigate this, by which point many people were seeing said lines. Further research turned up this master/root ticket of the implementation, which contains (read the comments/replies slowly) evidence of failed engineering design choices: blindly assuming Internet access was available to the system on boot (and blocking the boot process as a result), which is not the case for systems behind firewalls with strict outbound ACLs (i.e. expect a very long timeout to that TCP SYN to destination port 443) or on 100% private networks (no Internet access at all). The type of data included in client headers (during HTTP/HTTPS GET) also came into question.

The effort was done entirely by what appeared to be a single Canonical employee: Dustin Kirkland.

This is exactly why you don't implement stuff like this. To assume the system is connected to a network that has Internet access is faulty. If you implement a timer or queue-based system, again you are making assumptions about the availability of the network (and reachability), DNS setups, and so on -- it's literally a waste of resources in every way (CPU time, any logging, temporary files, general disk I/O, forking of processes, etc.). Furthermore, in some cases, it may actually violate company policies -- disclosure of some information to remote parties about the local system (most administrators wouldn't know about this in advance, and possibly wouldn't even know how to disable it).

KISS principle applies: you don't have to worry about opt-in vs. opt-out if crap like this is never implemented in the first place; there's no problem to solve if you don't create the problem.

In general, Canonical needs to stop trying stuff like this. For whatever reason they repeatedly have shown they do not think about the full ramifications of their actions. They seem to believe the entire Ubuntu userbase is running their OS on residential desktops, not servers on 100% segregated networks. I don't care if the opt-out is in GNOME only, everyone should be questioning "where" and "how" this is implemented on the system, given their track record.

Anyone who uses the stock Ubuntu AMIs on AWS EC2 knows that there is no "installation" -- you get a bootable and usable OS instantly.

So, will this feature be enabled by default in those AMIs? If so, how can one opt out of it as early on as possible so that nothing gets transmit to Canonical *ever*?

This distantly reminds me of the Canonical's choice to stick content of their choosing into your MOTD. I got wind of this because our Ubuntu-based systems in AWS suddenly had lines talking about irrelevant TV shows in our MOTDs. A ticket was filed to investigate this, by which point many people were seeing said lines. Further research turned up this master/root ticket of the implementation, which contains (read the comments/replies slowly) evidence of failed engineering design choices: blindly assuming Internet access was available to the system on boot (and blocking the boot process as a result), which is not the case for systems behind firewalls with strict outbound ACLs (i.e. expect a very long timeout to that TCP SYN to destination port 443) or on 100% private networks (no Internet access at all). The type of data included in client headers (during HTTP/HTTPS GET) also came into question.

The effort was done entirely by what appeared to be a single Canonical employee: Dustin Kirkland.

This is exactly why you don't implement stuff like this. To assume the system is connected to a network that has Internet access is faulty. If you implement a timer or queue-based system, again you are making assumptions about the availability of the network (and reachability), DNS setups, and so on -- it's literally a waste of resources in every way (CPU time, any logging, temporary files, general disk I/O, forking of processes, etc.). Furthermore, in some cases, it may actually violate company policies -- disclosure of some information to remote parties about the local system (most administrators wouldn't know about this in advance, and possibly wouldn't even know how to disable it).

KISS principle applies: you don't have to worry about opt-in vs. opt-out if crap like this is never implemented in the first place; there's no problem to solve if you don't create the problem.

In general, Canonical needs to stop trying stuff like this. For whatever reason they repeatedly have shown they do not think about the full ramifications of their actions. They seem to believe the entire Ubuntu userbase is running their OS on residential desktops, not servers on 100% segregated networks. I don't care if the opt-out is in GNOME only, everyone should be questioning "where" and "how" this is implemented on the system, given their track record.

Two extensions that I have used have not been ported. One was not ported because it depends on legacy APIs known to lack a counterpart in WebExtensions.

Having been a big Ubuntu fan (yes, including Unity) for quite a while now, I have been severely underwhelmed by the 16.04 LTS. The thing that really gives me pause (in addition to the basic instability of what is supposed to be a stable release) is the show-stopper bugs in major projects that have gone not only un-fixed, but unaddressed for nearly two years.

Here's one (Status: confirmed / Importance: High / Assigned to: Unassigned)
https://bugs.launchpad.net/ubu...

Here's another one (Status: confirmed / Importance: High / Assigned to: Unassigned) :
https://bugs.launchpad.net/ubu...

Both of these examples are _major_ bugs in _major_ packages in the distro. And nobody has bothered to work on them, at all. This suggests to me that Ubuntu is too short on manpower to actually maintain the distro at an acceptable level.

Canonical, WTF?

Having been a big Ubuntu fan (yes, including Unity) for quite a while now, I have been severely underwhelmed by the 16.04 LTS. The thing that really gives me pause (in addition to the basic instability of what is supposed to be a stable release) is the show-stopper bugs in major projects that have gone not only un-fixed, but unaddressed for nearly two years.

Here's one (Status: confirmed / Importance: High / Assigned to: Unassigned)
https://bugs.launchpad.net/ubu...

Here's another one (Status: confirmed / Importance: High / Assigned to: Unassigned) :
https://bugs.launchpad.net/ubu...

Both of these examples are _major_ bugs in _major_ packages in the distro. And nobody has bothered to work on them, at all. This suggests to me that Ubuntu is too short on manpower to actually maintain the distro at an acceptable level.

Canonical, WTF?

In this case, at least one person involved was unable to resolve it by replacing the CMOS battery:
https://bugs.launchpad.net/ubu...

From the Canonical bug report:
At least on Lenovo Thinkpad Yoga, the BIOS seems to monitor the SPI-NOR
write protection bit and if it is flipped to read/write it assumes the
BIOS configuration was changed on next reboot. It then, for unknown
reasons, resets the BIOS settings back to default.

a world class enterprise platform

Are you fucking kidding me? I have fond memories of canonical not fixing the following (and similar) bugs for years:

https://bugs.launchpad.net/libgcrypt/+bug/423252
https://bugs.launchpad.net/ubuntu/+source/libnss-ldap/+bug/1024475

a world class enterprise platform

Are you fucking kidding me? I have fond memories of canonical not fixing the following (and similar) bugs for years:

https://bugs.launchpad.net/libgcrypt/+bug/423252
https://bugs.launchpad.net/ubuntu/+source/libnss-ldap/+bug/1024475

You can actually see the lists of changes in the Ubuntu kernel git repos:

• Ubuntu AWS kernel git log
• Ubuntu Azure kernel git log

The changes range from configuring things off for hardware that will never exist on that platform, forcing certain options to speed up things like boot times, additional new drivers that aren't (yet) upstream (in one case the driver added was actually rejected by the mainline kernel maintainers and was pulled out of the Ubuntu tree later), backports of tweaks that were made in later kernels that help that platform etc.

One downside is that this makes a bit more likely that people running on cloud platforms could see different problems to "bare metal" setups (and vice versa) thus splintering the test effort a bit and increasing Canonical's maintenance burden. Also porting a VM with optimized kernel means you have to remember to switch kernel package (but if you know what you're doing then injecting packages into an offline VM is easy). I guess the benefits outweigh the costs...

You can actually see the lists of changes in the Ubuntu kernel git repos:

• Ubuntu AWS kernel git log
• Ubuntu Azure kernel git log

The changes range from configuring things off for hardware that will never exist on that platform, forcing certain options to speed up things like boot times, additional new drivers that aren't (yet) upstream (in one case the driver added was actually rejected by the mainline kernel maintainers and was pulled out of the Ubuntu tree later), backports of tweaks that were made in later kernels that help that platform etc.

One downside is that this makes a bit more likely that people running on cloud platforms could see different problems to "bare metal" setups (and vice versa) thus splintering the test effort a bit and increasing Canonical's maintenance burden. Also porting a VM with optimized kernel means you have to remember to switch kernel package (but if you know what you're doing then injecting packages into an offline VM is easy). I guess the benefits outweigh the costs...

"Udev had mount event support but it was so buggy and wrong that they decided to remove it completely!"

Udev can detect mount events such as the DVD being ejected by the eject button on the front of the unit. From an old bug report in launchpad.net.

/etc/udev/rules.d/61-sr0-change.rules

KERNEL=="sr0", ACTION=="change", RUN+="/usr/local/bin/sr0_change.sh"

Also, they took away the ability to even change them in Unity as of 16.04. An Ubuntu dev had this to say when someone filed a bug about it:

"The window controls in Unity are on the left. It is not a setting, it's where the designers chose to place them. This will not change."

https://bugs.launchpad.net/ubu...

It's ironic that they should justify doing this with a poll, since when they moved them in the first place Shuttleworth specifically said that he didn't care what the users thought:

"No. This is not a democracy. Good feedback, good data, are welcome. But we are not voting on design decisions."

https://bugs.launchpad.net/ubu...

It's abundantly clear that systemd-resolved has quickly become a train wreck. It's inclusion in Ubuntu 16.10 was widely lamented and many folks have pointed out huge concerns for several different assumptions that it makes for fallbacks and erroneous configurations. That's not including the several different bugs that have plagued systemd-resolved thus far. Granted many of them are fixed but with the breakage what have we bought? Something that's a pretty basic task now requiring patch after patch. Additionally, what has this solved? Now we can make DNS configuration a bit easier to integrate across the board?

The bad rep that systemd especially resolved has obtained isn't just simply one where grey breads say "it's too different". It is one that time and time again, ignorant assumptions, bloated egos, and hasty code have led to a general distrust, especially when tools that have always worked are suddenly not working or worse still, become methods for exploits. I still think systemd is a vast improvement over the "ye olde init scripts", but while the idea is commendable, it's execution has been somewhat lack luster to put it mildly. There needs to be a serious "Come to Jesus" moment for the systemd team. You need to build trust if your going to build something that's rewriting the books. This is just another example of how that trust is being chipped away. Complexity of the task at hand aside, either the team is up to delivering or they are not. This ostinato where breakage just keeps happening needs a serious all hands or something to restore trust in the team guiding this project. Poettering, you are doing no favors to yourself nor your team by these stories. Deliver us from the hell of bad init if that's what you seek, but don't plunge us deeper into a different hell of your making and say that it's alright because you're the one who built it.

It's abundantly clear that systemd-resolved has quickly become a train wreck. It's inclusion in Ubuntu 16.10 was widely lamented and many folks have pointed out huge concerns for several different assumptions that it makes for fallbacks and erroneous configurations. That's not including the several different bugs that have plagued systemd-resolved thus far. Granted many of them are fixed but with the breakage what have we bought? Something that's a pretty basic task now requiring patch after patch. Additionally, what has this solved? Now we can make DNS configuration a bit easier to integrate across the board?

The bad rep that systemd especially resolved has obtained isn't just simply one where grey breads say "it's too different". It is one that time and time again, ignorant assumptions, bloated egos, and hasty code have led to a general distrust, especially when tools that have always worked are suddenly not working or worse still, become methods for exploits. I still think systemd is a vast improvement over the "ye olde init scripts", but while the idea is commendable, it's execution has been somewhat lack luster to put it mildly. There needs to be a serious "Come to Jesus" moment for the systemd team. You need to build trust if your going to build something that's rewriting the books. This is just another example of how that trust is being chipped away. Complexity of the task at hand aside, either the team is up to delivering or they are not. This ostinato where breakage just keeps happening needs a serious all hands or something to restore trust in the team guiding this project. Poettering, you are doing no favors to yourself nor your team by these stories. Deliver us from the hell of bad init if that's what you seek, but don't plunge us deeper into a different hell of your making and say that it's alright because you're the one who built it.

Web Browser: Firefox, Chromium
        Email Client: Gmail web, Thunderbird
        Terminal: Byobu
        IDE: Eclipse
        File manager: Dolphin (I would love to use Nautilus but https://bugs.launchpad.net/ubu... makes it unusable to manage pictures)
        Basic Text Editor: Geany, GEdit
        Office Suite: LibreOffice, Gnumeric
        Calendar: Google Calendar web
        Video Player: vlc, totem
        Music Player: Audacious

Same AC here. On Linux, this is how you'd do that is below -- preface: I do not use X/X.org (last time was in 1995!), so please take some of what I say with a grain of salt. The version of Ubuntu you're using matters greatly too. Someone more familiar with Ubuntu as a workstation/desktop, please comment!

1. Try digging around for resources relating to X.org, as that's effectively what's driving all the GUI bits and interacting with the video driver. I think this is xorg.conf or xorg.conf.d/ and there may be a config file setting (warning: that file/directory will probably scare you). I don't think your WM (window manager) is relevant,

2. Research options described in Ubuntu's Community Support; pick one or several and post there,

3. Try to track down the authors (committers) of the associated video driver and ask them. I did the work for you as best as I could: the X.org driver is called xserver-xorg-video-intel (assuming that's the chip you're using). There's supposedly an alternate driver from Intel themselves here but I have no idea if using it would solve anything (I wouldn't recommend doing the latter on a whim; I prefer to use Ubuntu packages natively if at all possible),

4. Use Launchpad to file a ticket with Ubuntu directly. Also advise searching their system to see if someone else has asked the same thing (try looking for separate terms "tearing", "vsync", "v-sync", or "vblank").

I also own an Intel NUC, but it's a headless server box for building third-party MIPS and ARM router firmwares, so I don't use the GUI (I don't even have a monitor hooked up to it). Plus we might have different NUCs (their on-die GPUs certainly differ between models), and I'm running a fairly old Ubuntu (intentionally).

Sorry I couldn't be of more help, but the above steps is the road I would take if I had to deal with said issue.

Same AC here. On Linux, this is how you'd do that is below -- preface: I do not use X/X.org (last time was in 1995!), so please take some of what I say with a grain of salt. The version of Ubuntu you're using matters greatly too. Someone more familiar with Ubuntu as a workstation/desktop, please comment!

1. Try digging around for resources relating to X.org, as that's effectively what's driving all the GUI bits and interacting with the video driver. I think this is xorg.conf or xorg.conf.d/ and there may be a config file setting (warning: that file/directory will probably scare you). I don't think your WM (window manager) is relevant,

2. Research options described in Ubuntu's Community Support; pick one or several and post there,

3. Try to track down the authors (committers) of the associated video driver and ask them. I did the work for you as best as I could: the X.org driver is called xserver-xorg-video-intel (assuming that's the chip you're using). There's supposedly an alternate driver from Intel themselves here but I have no idea if using it would solve anything (I wouldn't recommend doing the latter on a whim; I prefer to use Ubuntu packages natively if at all possible),

4. Use Launchpad to file a ticket with Ubuntu directly. Also advise searching their system to see if someone else has asked the same thing (try looking for separate terms "tearing", "vsync", "v-sync", or "vblank").

I also own an Intel NUC, but it's a headless server box for building third-party MIPS and ARM router firmwares, so I don't use the GUI (I don't even have a monitor hooked up to it). Plus we might have different NUCs (their on-die GPUs certainly differ between models), and I'm running a fairly old Ubuntu (intentionally).

Sorry I couldn't be of more help, but the above steps is the road I would take if I had to deal with said issue.

Nevermind that they apparently embed system information into the User-Agent header that has no business being there. https://bugs.launchpad.net/ubu...

I'd call this criminal data exfiltration.

From ticket 1701068.

A quote from the wonk responsible for the code

- This was quite interesting, in that for almost 40 years of Linux/UNIX, the "Message of the Day" was anything but that... It was a message that was created at one point in time, when the distro released, and that's about it. And we managed to change that.

Really?, I must have imagined all the fucking times I'd updated the file with system and network specific information across the servers and workstations (Suns, SGIs, Alphas, Linux & *BSD boxes) I used to administer over the past 30 years. (I'm out of the F/T IT game now)

Linux could do well without these short of scheißkerle and their code pissing in the water supply (it does not surprise me in the least that this abomination in it's current form 'leverages' some systemd function), sure, it's limited to a specific subset of distros and can be avoided, that's not the worry, the worry is that there are people out there writing code for Linux who think that what this code implements is a good idea...and that's a bad sign. Not that it'll bother me much longer what the hell goes on with Linux distros in general anyway as I'm currently in the process of migrating everything to *BSDs, starting with my critical systems,

There's too much of this sort of BS now going on in the Linux world, Kids, Lawn, GTF off it.. etc. etc.

The thing is, it wasn't ever "accepted" -- instead, the committer (Dustin Kirkland) simply chose to do it and committed it. It began October 2016. Ticket 1637800 has the details. In this ticket, you can see how it was first implemented, and how this particular committer was not thinking about the bigger picture (esp. installs on systems which do not have Internet access, or network access at all). Read comment #3 for an example. The methodology was changed (at the request/demand of someone else, not the committer) to use a systemd timer and become asynchronous, which in the committers mind apparently "made everything OK". Subsequent users cited more concerns (see comment #8 onward) which have been ignored. You will also see a Canonical employee trying to perform some kind of political spin or mindfuck in comment #12 (thank you for the description -- it is still inappropriate and unprofessional).

People disagreeing with this feature are urged to comment in either ticket 1637800 or ticket 1701068. Bare it shouldbe disabled by default, else Canonical has learned nothing from the Unity Dash/Amazon ordeal. This isn't as bad as that, but it's definitely the same sort of thought process.

The thing is, it wasn't ever "accepted" -- instead, the committer (Dustin Kirkland) simply chose to do it and committed it. It began October 2016. Ticket 1637800 has the details. In this ticket, you can see how it was first implemented, and how this particular committer was not thinking about the bigger picture (esp. installs on systems which do not have Internet access, or network access at all). Read comment #3 for an example. The methodology was changed (at the request/demand of someone else, not the committer) to use a systemd timer and become asynchronous, which in the committers mind apparently "made everything OK". Subsequent users cited more concerns (see comment #8 onward) which have been ignored. You will also see a Canonical employee trying to perform some kind of political spin or mindfuck in comment #12 (thank you for the description -- it is still inappropriate and unprofessional).

People disagreeing with this feature are urged to comment in either ticket 1637800 or ticket 1701068. Bare it shouldbe disabled by default, else Canonical has learned nothing from the Unity Dash/Amazon ordeal. This isn't as bad as that, but it's definitely the same sort of thought process.

System76 is hindered by Ubuntu because Ubuntu is hindered by Canonical. Surely there's a better source for a fork. I get that they have lots of Ubuntu experience and a history there, but Launchpad should be EOL.

Here
Have fun trying to debug that without having one of the affected hardware platforms.

The only thing I like about Shuttleworth is that he is a pretty motivated guy and actually manages to get things implemented (as opposed to the next 1000 guys with ideas that do nothing about them).

I think his problem is that he holds on to a losing model way too long (sort of like when you have a stock and it's going down and down and down and you are only relying on hope at that point when realistically you should cut your losses).

There is evidence to his broken model from an interview with him about 7 years ago when he was being asked about his "famous" Ubuntu Bug #1: Microsoft has too much market share. https://bugs.launchpad.net/ubuntu/+bug/1

He said, in that interview https://raphaelhertzog.com/2011/11/17/people-behind-debian-mark-shuttleworth-ubuntus-founder/ that this would be the solution: "The key to that dream is economics, and as always, a change in economics; it was clear to me that the flow of money around personal software would change from licensing (“buying Windows”) to services (“paying for your Ubuntu ONE storage”)." But I don't think that jives with reality. I don't think you can dominate with an Open Source project based on ideas relating to money.

You can even read in his blog and articles that his biggest frustration with Debian is that one person was not in charge, so it lacked a unified vision. That's great, but everything Shuttleworth does he wants to be the leader in, which is why he goes about re-implementing Canonical-only projects that already exist in the Linux-sphere that he could work with instead. And the problem with wanting to be the leader of everything is that when you are wrong you must realize it or you end up far outside of reality. But maybe he is starting to realize it now.

Title: 'Mir will cause fragmentation in Linux on desktop' - (You be the judge and tell me if I'm wrong.) I personally like Ubuntu and am worried about this step they are taking. https://bugs.launchpad.net/mir...

Some of our Linux servers that are not exposed to any hostile networks and inconvenient to reboot (e.g. monitoring display server that is displayed, along with other stuff, on a 30mx6m video wall) have uptimes of 5 years or more.... I also can't think why systemd would have any impact on uptime ...

5 years? Seriously? You're running on an 5 year old kernel with multiple known issues (TLS, OpenSSL, etc)?

I didn't say they don't get any updates at all. They just don't have kernel updates applied. There are multiple firewalls protecting these specific servers from hostile users/networks, and 90% of the people who have any access at all (e.g. HTTPS access) have sudo rights to run various things as root on them anyway. The only systems that have any firewall access to them are the other monitoring servers, and all the monitoring software is kept up-to-date.

As for systemd, you must not be very well versed in it. SSH Fails,

Yes, some versions of systemd introducing new features may have bugs. Only immature distros would push such versions out to users of stable releases.

NTP

Using timesyncd isn't mandatory. The distro I use on my laptop doesn't use it, RHEL7.3 doesn't ship it.

magically fixed a service startup issue, no one knows why,

Doesn't seem like anyone could reproduce that on other versions (shipped in stable distros, or current).

and just a general list of why systemd sucks.

Of the 5 major complaints, 3 are about the journal. There are some advantages to it, and some disadvantages, and I think systemd should support not using journald at all, but you can avoid relying on the journal itself by forwarding to syslog and disabling storage.

Regarding giving block devices for filesystems listed as required in /etc/fstab, this is a conscious design decision that is required in environments with complex storage (many storage arrays in a complex storage area network). The alternative (with e.g. sysvinit) is to have your production database servers fail to come up at boot time because the init system didn't give enough time for all 100 LUNs to appear so that it could mount the filesystems required to let the database start. It is really fun to have to be woken up to get such systems back up after a rack has tripped because then engineer on standby can't figure out what to do, I'd rather have systemd do the right thing. As far as I know, the default timeouts have been reduced (systemd wasn't hanging though ... it was waiting for devices it was told were required to appear) and provide more information on why it is waiting.

The 4th issue is cosmetic, and applies to most kernel drivers ... only dracut namespaces its parameters (rd.xxx).

And that took all of 2 min to search, read, and compile, because I wanted to give you some solid backing for stating it sucks.

Yes, it is trivial to find old bugs that are fixed, and FUD complaints from systemd haters about behaviour that has been improved.

You're in RH land with supported versions, so it's likely that these problems, when they crop up, are offloaded as RH issues and you just monitor a trouble ticket. Lucky you. I guess I wouldn't care in that scenario either, as it's SEP.

Our production servers run Red Hat. We haven't needed to log a ticket for anything systemd-related.

My workstation, my laptop, and the desktop my wife uses at home run a different distro not associated with Red Hat at all that switched to systemd long ago, and I have seen no issues there either.

Some of our Linux servers that are not exposed to any hostile networks and inconvenient to reboot (e.g. monitoring display server that is displayed, along with other stuff, on a 30mx6m video wall) have uptimes of 5 years or more.... I also can't think why systemd would have any impact on uptime ...

5 years? Seriously? You're running on an 5 year old kernel with multiple known issues (TLS, OpenSSL, etc)? I hope they're firewalled well. As for systemd, you must not be very well versed in it. SSH Fails, NTP magically fixed a service startup issue, no one knows why, and just a general list of why systemd sucks. And that took all of 2 min to search, read, and compile, because I wanted to give you some solid backing for stating it sucks. You're in RH land with supported versions, so it's likely that these problems, when they crop up, are offloaded as RH issues and you just monitor a trouble ticket. Lucky you. I guess I wouldn't care in that scenario either, as it's SEP.

I have used Linux for 21 years already, going from Suse to Ubuntu and then Mint after Unity was introduced. I could not be happier on my new job when I started 1 december that I was allowed to choose my own laptop as long as it was made by their preferred supplier. As a web developer I favor screen real estate more than the portability of a laptop, so I was very happy I noticed the Intel NUC 6 which I fitted with 2 x 24"monitors. I installed Mint 18 on it and was as happy as any /. reader could be.

Until my screen froze, not responding to mouse or keyboard. I disabled the screen saver, but when I was resizing a window it froze on me again. About 2 times per day. i ran all the updates I could run and now have it down to 1 screen freeze every 2 days. I think it is bug 1321623. https://bugs.launchpad.net/lin...

When I see they were perfecting the screen savers for Mint 18.1 while this bug kills my productivity it annoys me quite a bit.

If only they could restore the type-ahead functionality they removed in 3.6, I would be satisfied. https://bugs.launchpad.net/ubu...

Systemd-logind must be restarted every ~1000 SSH logins to prevent a ~25s delay

https://bugs.launchpad.net/ubu...

Except... it wasn't a systemd bug at all. Per comment #16:

Ok, with everyone confirming that the systemd patch is not required, I am closing the systemd part of the bug as 'Invalid' - let's only concentrate on the dbus part here. That being said, I would not like to release a new patch for dbus downstream if the patch hasn't been fully reviewed and approved upstream. In this case I would propose to wait a bit and see if a finalized patch will be available.

Not that the presence of one bug in systemd would indicate that the whole approach is a bad idea... but it's rather funny that the one example you pick turns out not to be a systemd bug at all.

Systemd-logind must be restarted every ~1000 SSH logins to prevent a ~25s delay

https://bugs.launchpad.net/ubu...

Except... it wasn't a systemd bug at all. Per comment #16:

Ok, with everyone confirming that the systemd patch is not required, I am closing the systemd part of the bug as 'Invalid' - let's only concentrate on the dbus part here. That being said, I would not like to release a new patch for dbus downstream if the patch hasn't been fully reviewed and approved upstream. In this case I would propose to wait a bit and see if a finalized patch will be available.

Not that the presence of one bug in systemd would indicate that the whole approach is a bad idea... but it's rather funny that the one example you pick turns out not to be a systemd bug at all.

Systemd-logind must be restarted every ~1000 SSH logins to prevent a ~25s delay

https://bugs.launchpad.net/ubu...

I am sure putting all the eggs in one basket will be fine, in the long run

That was a problem, but I had disabled that. It was some dbus process run amok . Every time I thought it was fixed, I would wake up to a 100% pegged CPU that had been that way for who knows how long.

I agree, I use updatedb/locate/find/grep

I think I will install the new LinuxMint18 XFCE as soon as it is released and try KWIN with it (on an older unused PC or in a VM) and see how it goes.

There are several bug reports on variations of this problem (some about the position, some about the wrong desktop, some about programs that won't restart). Here's one of them.

> 4. virtual desktops
--So far, this is the only "killer feature" that I have seen so far with Win10 (I upgraded my Win7 laptop in-place but have not used it in months since I found out about Win10 == spyware PLUS braindead break-your-apps anti-user garbage PLUS reboot-whenever-it-senses-$CRITICAL-THING--that-you're-right-in-the-middle-of)

( Aside - you like ST:TOS, you can't be all bad ;-) )

> 4. Most IT folks here after 40 HATE CHANGE. Read anything about systemD, WIndows 7 (pre 2014), or anything else?
--LOL, u nailed it man ;-) One of the reasons we "hate change" is more often than not, change BREAKS THINGS that we have been depending on for YEARS in some cases...

( This is a bug in Ubuntu 14.04 that I just started dealing with - note the lack of support and concern from Canonical over what is a very serious issue for sysadmins: )

https://bugs.launchpad.net/ubu...

Arch gets a mention purely because of the high quality of their documentation. I know you know how important good documentation is. Otherwise Debian Stable is very good, or maybe Ubuntu 16.04 (LTS) if you do Steam gaming. Ubuntu has a really easy way to set up private software distribution channels (PPAs), which is both a good and bad thing. Good, in that you can almost always find some sort of niche repository for addressing some system issue, and bad in that too much messing with software sources tends to result in shall we say unpredictable performance. Also, if you really like to "go fast and break things," Fedora is the headwaters of a huge part of the Linux ecosystem.

Cinnamon is a good desktop environment, but not worth installing Linux Mint. Otherwise, KDE will probably be the easiest to pick up. XFCE/LXDE are fast and customizable, but will probably require that you do some customization. Use zsh in preference to bash, and use ssh whenever possible. Cheers!

They should add the ability so sync contacts and calendars using CardDAV and CalDAV.

This has been an issue for some time, the discussion between Ubuntu Phone users has been going on for a while, as can be seen here, for example.

A related bug report (open since 2013) can be seen here.

For now, a Google account is the only option the GUI allows to sync contacts and calendars. If you're doing that, what is the point in using Ubuntu on the phone, might as well use Android.

I'm aware that syncevolution can be used on the phone's command line but really, adding an OwnCloud server (for example) should not require enabling developer mode and adding scripts setting up cron jobs. This very simple omission is what's keeping me from using Ubuntu on the phone. I'd quite like to keep my data from Google or Apple or Microsoft and I fail to see why the management team behind Ubuntu Touch can't see this use - I know I'm far from the only one.

By the way you can easily install Ubuntu on a Nexus 4 using the images provided. It's a fairly ok to use - certainly miles ahead of FirefoxOS - but I was hoping they would have implemented this by now, I first tried it at release 9 so they've had 2 major opportunities to enable it.

Last time I checked, I couldn't use F11 to full-screen Gnome Terminal and then F11 to get it back to it's original size. Advanced feature I know, but I use the terminal a lot!

And that's what I really really really fucking hate about Ubuntu LTS releases... so much stuff is broken, and never actually get's fixed. So I wind up having to faff with PPAs afterwards and then hoping that the next LTS will have things fixed.

You're absolutely correct! I've been using Ubuntu since 6.06 and it's been vastly better than Windows for me.

But there are things that are annoying. For me, it's mostly where LTS releases tend to be released with irritating bugs that may never be fixed; instead they'll get fixed in the next version, and as an LTS user, you've either got to get a back port, or a PPA to solve it.

I've not done much testing with 16.04 yet, but this bug is *really* annoying: bug 1521302

And I've a horrible feeling it won't be fixed before release, and so, I won't want to upgrade until it is fixed or there's a work-around.

So yeah - broadly, Ubuntu is great. But... grrrr... annoying stuff too!!!

Every year or so, I get the urge to replace Xubuntu with Debian on my desktop and development systems. Sadly, it just doesn't make sense to do so. Ubuntu still has a few huge advantages over Debian. In particular:

Ubuntu's bug tracking system is far more convenient than Debian's, provides richer categorization and relation tools, and integrates with upstream trackers. I waste less time when I have to report problems, and since more people are sharing knowledge in launchpad, I also waste less time on diagnostics and fixes. Average users find it more approachable, too, and can often use it to find a workarounds for problems that they need solved before the next Debian release cycle crawls around.

Ubuntu's personal package archive system is both a public build farm and an open software repository. This means I can share custom software packages with others, with no bureaucratic overhead, on any release schedule I choose, through a channel that's extraordinarily easy for users to install, with integration into the standard system update process. Oh, and I don't have to set up build environments for multiple architectures (or in some cases, any build environment at all). Of course, all of this also benefits non-developers, by giving them access to a lot of software that isn't part of the Debian archive.

Last time I checked, Ubuntu still had far better support for certain important hardware components, like my graphics card. I'm an advanced user, so I could probably jump through the hoops to get proprietary drivers working in Debian, but most people don't have that kind of knowledge or the time/inclination to develop it. I wish there was a way around this by simply choosing different hardware, but there simply is no good substitute for certain proprietary devices. (Linux gamers can either use nVidia hardware with the closed driver, or be stuck with inferior performance.)

Despite Ubuntu making some dumb decisions and pissing me off at times, it honestly has done a lot to advance linux. I'd like to switch to Debian, but honestly, it would just make my life harder. I hope it catches up soon.