A Thank-You Note to the Hacker News Community from Ubuntu
blog.dustinkirkland.com
blog.dustinkirkland.com
Now they do it again with Wayland/Mir! It actually takes a significant amount of both balls and goodwill to give up on the product that you invested so much into for the sake of aligning better with your open source community. Bravo!
FWIW, I too would like to keep the DE experience of Unity, and especially the Dash panel and shortcuts. If that expose-text-search could scan non-focused browser tabs that would be a killer feature, but that's for the other thread.
The idea of "Let's simply ask HN users what they think" is a gem, that I suspect will now make it into many PMs' playbooks ;)
Maybe switch to KDE’s KRunner? It’s the most functional and extensive search framework yet.
https://news.ycombinator.com/item?id=14044287
I think there was a lot of hate for PulseAudio too.
I wonder what about Kay Sievers now, which was even hated by Linus Torvalds at one point.
I am sure the people who hate it have good reasons, but all I've heard is 'doesn't follow UNIX philoshophy', (guess what, the whole Linux ecosystem doesn't really, even Stallamn isn't a fan), 'centralized', (somewhat valid, but there's still Gentoo and Void Linux), binary text files, (installing a 'text logger' over journalctl takes 5s and the filtering capabilities of journalctl are awesome).
Also, the hate for PulseAudio largely died years ago. I for one am glad for people like Pottering, who are willing to think longer term and produce great* software.
Yes, maybe more buggy at the start, (but not really the case with systemd), but great eventually. Also, let's be honest, the reason you see more bugs in i.e. PulseAudio is because it is being developed in the open from its inception.
ZFS is not compatible with the GPL. Canonical is treading a risky path with what they're doing.
I would love ZFS to be native on Linux, BTFS has had too many scary data loss bugs to be able to trust it.
And I know a lot of musicians who still find PulseAudio not fit for purpose. There's no hate, just frustration at the adoption of a bad solution crowding out ones that work better for their given use case.
I listed the ones I could find and stated why I disagree with them, you could've made this a useful post by listing some additional ones, but instead you choose to just spell, (miscase?), systemd wrong.
It was the same with init, but instead of digging into greppable script files, you need to dig into Google and systemd manpages first, then dig into the actual issues second.
PulseAudio actually implemented a Dbus API to release its lock on the AlSA device. jack2 can use this automatically take over when it starts. There also exists two-way sound transport for sending sound from Pulse to JACK. If that was automatically set up also, then we would have a plug & play solution for pro/real-time audio on Linux.
For example, how do you like the fact that init now comes with "hidden" timers ? After you've scoured every place that a "traditional" Linux might put scheduled tasks, you've come to the realization "Ooooh, now my init has its own cron!". Because obviously an init system needs its own cron!
Or the subtle way it breaks existing SysV compatibility. An RPM/Deb package drops its SysV init file at /etc/init.d, and the next thing your ConfigManagement system does is try to start the service - quite standard. Bang - "Unit not found"! Why? Now on systemd-enabled flavors, you need to reload the mofo after dropping in your files. Of course Systemd could hook into dbus and run crons, but it can't be bothered to inotify or even jit-check-upon-request /etc/init.d. Because subtle breakages are cool!
How about the systemd-hostnamed service? Why on earth would we need a service to change the hostname? And why should it care about the "chasis type" of the machine?
These are just some of my own WTFs encountered during my admittedly short but language-colorful interaction with systemd. I have nothing against the Systemd unit files, but the functionality/bug scope of the whole thing is way bigger than I'd feel comfortable with!
P.S. Poettering is reportedly a townie, so I'd love to buy him a beer someday and berate him over it.
They're not "hidden", just managed with systemctl like other services, you can still use regular cron if you'd like.
As to the rationale of including timers, it is for stuff like mounting and unmounting remote disks etc, at boot, which I personally would include under the responsibilites of a modern init system and 'system manager' in general, same with taking care of TRIM every so often etc., but I appreciate that it isn't for everyone.
> Or the subtle way it breaks existing SysV compatibility.
The SysV init scripts would regurarly break in subtle ways by themselves to be honest, I find systemd a much saner option.
> How about the systemd-hostnamed service? Why on earth would we need a service to change the hostname? And why should it care about the "chasis type" of the machine?
The systemd network stack is entirely optional and intended for scenario where you can't afford/don't need the 'fatness' of NetworkManager, just because it's there, doesn't mean you have to use it.
> P.S. berate him over it.
Plenty of people already did so, over and over, but have fun, considering you'd be buying him a beer...
Currently.
The implementation is retarded. Last week my providers' iSCSI fabric suffered a glitch, which hosed a whole bunch of servers for hours because systemd refused to boot when it found the volumes not present. These were in no way critical to the operation of the stack. However, some moron somewhere decided that locking the system for 5 minutes on boot, and then simply refusing to boot properly, when everything required to boot is actually in place and OK is the correct course of action. I have enough of that kind of deranged thinking to deal with coming from Windows, I don't need it from my Linux machines.
Systemd sucks for servers. It might do a lot of nice fancy tech stuff, but it is extremely poorly thought out for use on the server.
This is not normal systemd behaviour, it waits for the resource, but only 1min 30s by default and then continues booting, (unless the services are considered critical for reaching certain target), logging a failed service, someone must have therefore explicitly configured a custom behaviour in your situation.
> The implementation is retarded.
May be, or may be whoever configured the server this way is, who knows?
> I have enough of that kind of deranged thinking to deal with coming from Windows
As I said above, this is not standard systemd behaviour.
I am not saying that systemd is perfect, but your case seems like misconfiguration, rather than "deranged thinking" from the systemd devs.
I'l encarouge you to read more on its configuration, it's actually fairly flexible, this[1] is a solid starting point.
1 - https://www.freedesktop.org/software/systemd/man/systemd.ser...
2 - http://stackoverflow.com/questions/33776937/how-to-change-th...
(this was originally meant as a reply to above comment was mistakenly posted to grandparent.)
So far in the history of nix, services have never equaled periodic tasks, to my knowledge. In that sense, it's a hidden surprise that would sooner or later bite everybody that has not been initiated in systemd. It makes things harder to debug.
> As to the rationale of including timers, it is for stuff like mounting and unmounting remote disks etc, at boot
Now do you go from that need to "and that requires an internal crond implementation in your init system". Why not atd, or regular cron, or sleeping processes? I'm genuinely curious, so if you're aware of public discussion of it, please point me in that direction.
> The SysV init scripts would regurarly break in subtle ways by themselves to be honest, I find systemd a much saner option.
I appreciate that the chaining and dependencies of SysV init were horrible. That doesn't make it OK for systemd to introduce more subtle breakages in even a very basic* usecase.
> The systemd network stack is entirely optional and intended for scenario where you can't afford/don't need the 'fatness' of NetworkManager
In the scenario where you do not need NetworkManager/GUI hostnamed would be quite worthless as well. /etc/hostname and the `hostname` command are more than enough to handle that case, thank you.
I guess my main issue with systemd is that it introduces (mostly?) unnecessary complexity, which makes me waste more time debugging problems. Of course it is better than SysV init, and I'm very happy with the syntax of system files. Yet, upstart showed that you can have those niceties without an excess of complexity.
If you want the hostname to be preserved across reboots, you need to save it on disk - canonically, in the /etc/hostname config file.
Since /etc/hostname is an important per-machine config file, you probably want it owned by root.
Since you may want to edit this config file from a GUI control panel of some sort that you launch from a desktop environment running under a non-root user, you need a mechanism for the control panel process to be able to change the config file.
There are several ways to accomplish this:
* run the control panel process under root (for example, using sudo). This is not a good idea, especially under X11, since GUI toolkit libraries are not security hardened, have a large attack surface thanks to various GUI IPC mechanisms, and your control panel process could be subverted by hostile processes that have been waiting in the background for just such an occasion to arise.
* put your non-root user in a group which has write access to /etc/hostname. This is the traditional Unix solution, but it's not very flexible. If your user was not in the hostname-writer group, you will have to log out and back in for the change to take effect. And you can't create policies like requiring entering a password before performing administrative-type actions (unless the password is for sudo - and that is dangerous, see above).
* run a daemon under root that allows making edits to /etc/hostname. Provide an IPC interface to request a change to /etc/hostname; have the daemon check, via a call to a flexible, configurable authorization service, that the caller process has the right to perform a "change /etc/hostname" action (the authorization service might reply yes if, for example, the caller's user belongs to a specific group and verified his password within the last N minutes); and only then make the change on behalf of the unprivileged caller.
The latter seems like a better solution. Maybe over-engineered for managing a one-line config file, but definitely the solution to go with for more complex situations; so we might as well use the general solution in this case too.
The daemon is hostnamed; the flexible authorization service is polkit. See https://www.freedesktop.org/wiki/Software/systemd/hostnamed/ for more details.
"sudo vim /etc/whatever.conf" is perfectly fine.
"sudo gedit /etc/whatever.conf" might give an attacker already on your system a way to gain root.
Yes, just keep doing that. I run several Linux boxes with systemd, all of them without hostnamed.
Forcing all your users to use the One True Way on a complicated system usually just means you're ignoring many legitimate use cases. Microsoft still does that on Windows (APIs and ugly registry entries over everything) - and while I cringe everytime I see it, I still recognize that the approach has value for some situations.
Many of the daemons for systemd on the other hand are optional, which I personally find to be great. I can use the ones I need and leave the ones I don't.
As for the GUI: Why use a text file? That might be a good use case for you and me, but a terrible one for someone not used to administrate *NIX systems. Why not allow both? As long as the file-based approach is not neglected, I'm perfectly fine with that.
While being a formally valid solution, it all seems like waste of simplicity and totally uncontrolled design process.
Good question! I've wondered about this before too, ought to research it.
> Is hostname the only thing with such problem, the only gui-configurable system-wide setting?
Of course not :) Systemd provides a half-dozen similar daemons for configuring things; hostnamed is probably the simplest one of them, so I was trying to justify why so much engineering went into something that looks so trivial: it's because the approach is generic.
The idea is that a non-systemd system could reimplement some of these daemons (or rather, their dbus interface; you could implement them in one executable if you want) - and the parts of a standard control panel application relevant to your system would just work.
This kind of excuse-making makes me rabid. "We will use our position of power to drag everybody through debugging our poorly made software because we are amazing and one day it will be great" is not a position I will ever have much respect for.
If somebody's enough of a genius to see the future of software, they're enough of a genius to make their shit work for the audiences they are currently shipping to.
But practically? The service-files are a pleasure to write, the documentation is excellent, and I've not personally had a failure I could attribute to systemd. (Though I did come close, learning that systems with an old version of "snoopy" installed wouldn't boot under systemd.)
If Slackware ever moves to systemd, it will be a sad day, but i'll keep using Slack because it's the whole distro that I want, not just how the system initializes services. If I could deal with Windows's bullshit, I can deal with systemd. Just like ConsoleKit, and PolicyKit, and NetworkManager, and UPower, and PulseAudio, and HAL, and UDev, and DBus, and all the other annoying crap that's been shoved down our throats over the years. Now I know how old people feel when they talk about modern cars...
That's an odd assumption. I have. I'm a big fan of standardisation.
I understand some people not liking systemd, but there are a lot of folks out there who really prefer it. Once I started adopting it, I no longer needed/wanted to support cross-distro start scripts, since systemd does that. So non-systemd distros were dropped.
By moniculture, are you saying that adopting systemd leaves you vulnerable to cross-distro vulnerabilities hitting a bunch of systems all at once? (Most of my knowledge on the downsides of monoculture come from Irish history) Or are you pointing to something else?
That's not a good standard for an operating system supposedly about flexibility, compatibility, and choice. And it's even more annoying for software which isn't intended to be run in a monoculture, like most of the open source/free software world.
And for that matter, did anyone make a systemd-to-sysv converter ? Because that should surely be possible, systemd service files being declarative.
If such a converter did exist, then suddenly, the systemd "service files" could become an actual standard, since they'd be (somewhat) compatible accross sysv and systemd. And maybe we could work from there and support other init systems...
Your suggestion of turning systemd's APIs and formats into a standard is not out of the question, but it would never happen. Poettering and his team showed they have zero interest in making a compatible system, or in making any concessions at all. Standards have to do both. And other platforms have to buy into the standard, otherwise it just sits there like a third leg.
The way it would probably end up is a project like Alien would adopt some of systemd's quirks. But so much of systemd is tied directly into the application via APIs that it would be a huge PITA to support both systemd and anything else - hence why some devs simply drop support for anything that isn't systemd. It's the same sort of thing that causes devs to only develop for Windows, or iOS/OSX, because it's more popular and porting to Linux is too expensive.
Another is daemonization. In traditional systems, long-lived processes daemonized themselves and took care of themselves. The big benefit was independence and flexibility. You don't have to do a lot of work to port it, or maintain it, or administrate it. A shell script and some simple conventions allow it to run in almost any environment, and all of the services basically worked the same way. Often this was out of the necessity of a complex program's needs, where the way it manages its tasks, or shares memory, or communicates with other processes, or handles signals, or is checkpointed, or debugged, etc may have had complex requirements.
But now, systemd recommends you not daemonize your process. Let systemd manage it for you! This works great for very simple services, but not so well for complex ones. Now people are writing more services that can't manage themselves and thus need something like systemd to take care of it, or it simply won't work as a daemon on a non-systemd system.
The systemd people would say, any system can adopt these calls and these methods! (Which is equivalent to saying, any OS can adopt Linux's completly nonportable and specific syscalls, even though they already have a working alternative) But that's not the end of it. Every piece of systemd that you adopt, then depends on other piece of systemd, so you can't just pick up one piece of the pie. You have to eat the entire thing.
We're moving more and more to having unified low-level services across Unices, so it stops being about stupid things like "Oh sorry, Arch can't run this because it uses its own audio stack even if we're just using audio to make a notification sound", and starts being about the things that are fundamentally different about the systems.
Think about how nice it is that we don't have to recompile most things for most kernel versions. Why do we have to set up multiple startup script mechanisms?
Yes, nobody has ever had to recompile their application to work on a new kernel. If you mean that's nice that there's binary backwards compatibility, I agree. I don't see what this has to do with supporting multiple systems.
> Why do we have to set up multiple startup script mechanisms?
Why do we have to support multiple <insert any kind of software> ?
> We're moving more and more to having unified low-level services across Unices
AFAIK, the only thing I know of moving toward middleware unification specifically is Linux desktop software. Choosing to use systemd in exclusion of everything else is "unification" in the same way that nationalism/xenophobia/homophobia are. (i'm aware of how mean that sounds, but it's the closest comparison I can think of)
It is certainly nice that there is now middleware that abstracts the underlying software that controls the hardware, for example, or that authentication and authorization are more uncoupled. But this is really almost the opposite of what systemd does.
I didn't write upstart units for that reason. I now write systemd units and it's wonderful.
Although I'm speaking with my sysadmin hat (I have a few hats). I have a lot of software deployed/managed through Ansible (from node/ruby/python apps to proprietary apps). They might not provide a unit file, so I have to write my own (and I might send it upstream).
The main pain point I encountered regularly, was making sure that the process starts at the right time, has proper stderr logging and monitoring. I rarely bump into kernel or library problems (but that's just me, I'm not denying the problem). I understand what you mean though, systemd is just one of the base components. It doesn't fix everything, but it helps.
On "write once": I feel bad for people who have to read the shell scripts I've written. I think they're good and I'm a fan of keeping it simple, but my scripts don't come with a manual. Any junior dev can understand my unit files (tangential: that's also why I like Ansible/Puppet/etc).
The benefits of that unification are very, very tangible for package authors/maintainers - they now have to write just one flavor of a service file. And that is a great thing(tm) for the Linux community as a whole - well worth my own gripes with systemd itself.
For me it's solving the problem of simply and reliably wiring up persistent and resilient services (not shipped with the OS).
I don't know about you, but that's a need I especially have on servers.
When systemd works, it works remarkably well.
That aspect was already largely solved, and has been for a long time. runit, upstart, daemontools etc.
Daemontools, like a number of djb's tools, manages to really manage to blend an amazing level of "just works" and "ZOMG, I configure this how?!"
Have been using it since it was introduced in Fedora 16 (as I was a fedora guy) and I've never been convinced of its use on a server.
I understand it solves some problems but does so while introducing new and harder to remedy ones. (like tight ABI integration).
I don't mind systemd (ok, I'd criticise it but not nearly hate it as much), but I don't like that it's now the default target which forces me to use it in future.
I'm a Systems Engineer, so I have different needs from servers than Developers I guess, I want things to be easy to debug and diagnose.
I will say that I'm not only accustomed to systemd or sysvinit, I've also used runit at scale, along with SMF on Solaris and openrc.
SMF Beats the pants off systemd, even if it uses XML internally.
They didn't do it to align with the open source community. They did it because Canonical wants outside investors, but potential investors don't think Unity can make money.
I personally am very happy with the current Unity. I find it intuitive and more aesthetically pleasant/polished than Gnome Shell (I've only used that as it comes with Ubuntu Gnome).
So please, don't drop current Unity. Or if you have to switch to Gnome Shell - please keep the user experience as close as possible to the current Unity to help users migrate.
Is Wayland better than Xorg? Yes, or at least it will be.
Wayland and Mir are distinct projects made to solve the exact same problem in the exact same problem space.
Usually this is a fine idea, but Wayland could really use the support that Canonical has avaliable, especially since it depends so heavily on graphics driver support, which Canonical can help push for using its association with NVIDIA (the only graphics manufacturer with a completely proprietary driver now).
Notice that Xorg doesn't have any real forks anymore. That is because it a much better idea to focus driver support on one library (graphics drivers are hard enough as it is). Unfortunately, Xorg has some inherent problems that Wayland is designed to fix; so until Wayland is complete and stable enough to replace Xorg, we need all our graphics drivers to target both stacks (Wayland and Xorg). That's already difficult enough without Mir demanding its own attention.
Again, I haven't looked at it lately, but the last time I did, mutter was just fantastic. I was tempted to write my own WM on top of it, but since I have grown disenfranchised with the rest of the Gnome ecosystem (and it's hard to pull that out of mutter), I gave up. This shouldn't be a problem with Unity, though, as it is already entrenched in Gnome.
https://igurublog.wordpress.com/2012/11/05/gnome-et-al-rotti...
https://davmac.wordpress.com/2016/07/05/why-do-we-keep-build...
I suppose Canonical are big enough to have their needs taken into account, unlike other app authors.
I think this is what ElementaryOS[1] did. It was funny/interesting to me that the "flashiest" features demoed on the website were pretty much just stock Gnome 3 features.
Good job, Canonical! Happy to be a user!
(And good job finally ditching Mir. You could have kept Unity for all I care. Linux can handle a few dozen DEs. But having more than one display server, now that was just nuts.)
Edit: while the feedback post here may have been the most discussed post on HN ever, the announcement of dropping Mir clearly made rumbles too, with a record 10,000+ upvotes in a "niche" subreddit like /r/linux. When a player like Ubuntu does the right thing, people clearly care.
I really like this one. I'd made comments of wanting pre-installed Linux, but the Nexus concept is a much better idea. It's following a model that seems to have worked well for Google.
It's a fantastic way to break the chicken and egg situation of getting pre-installed Linux available.
Offer a pre-installed Linux version of a machine at higher cost, but do your best to upstream patches and homogenize hardware with the Windows pre-installed version.
Seems to split the difference between "a Linux laptop is economically unfeasible" and "with a little care in component selection and upstreaming drivers / fixes, compatibility can be assured."
I actually find the fact that the Linux version is more expensive to be insulting. If anything, it should be cheaper, given that you're paying the "Windows Tax" on the W10 version of the laptop.
Now if they cost the same price, with the caveat that the $80 or so that would normally go to the W10 license is instead going to Dell's Linux team to ensure hardware compatibility and/or submit upstream changes to Canonical / Red Hat, then I'd be all for it.
I just created a product comparison¹ on Dell's site and it looks like the Ubuntu version of the XPS13 is $100 cheaper than the Windows version.
① - http://www.dell.com/us/business/p/configuration-compare.aspx...
This is the same reason why other sellers will happily give you a computer without an OS and take the price off, but they won't give you any even basic support for installing anything else.
If Linux users were willing to pay more, then there'd be an incentive for sellers to put the effort in pre-install Linux.
We (sadly) don't get the luxury of pretending the markets for Linux on laptop and Windows on laptop are identical except for the OS.
Unless things have changed since the Windows 7 days, you're paying the Windows Tax on both units. Dell (and other major manufacturers) pay Microsoft for every unit sold no matter what ends up on the hard drive. That's why it's half-jokingly called a "tax" in the first place, and it's likely why the Linux version costs more; the base price is the same no matter which OS is installed, and the little bit more you pay for the Linux model goes towards recouping that extra work integrating Linux.
> Now if they cost the same price, with the caveat that the $80 or so that would normally go to the W10 license is instead going to Dell's Linux team to ensure hardware compatibility and/or submit upstream changes to Canonical / Red Hat, then I'd be all for it.
I love that idea too, and maybe the smaller OEMs can get away with that if they have a per-install license fee from Microsoft instead of a per-unit-sold fee.
If you want other people to see your contact info put it in the about textbox.
So to me, the check and egg situation is already solved.
In your original story, I posted a request for Canonical to come up with some viable strategy to get Adobe CS (and related color-calibration HW/SW) usable on Ubuntu.
I expected a lot of traction for that suggestion, because AFAICT a lot of creative professionals are looking for a way to escape the Windows/Mac duopoly.
However, it looks like my suggestion didn't make the cut for the list you just posted.
Can you share any thoughts on why getting Adobe CS usable on Ubuntu is / isn't a strategic priority for Canonical?
We're engaging with dozens of major vendors of traditional/proprietary software about delivering their software onto Ubuntu via Snaps -- which is a new packaging format that solves many of the traditional problems associated with proprietary software working well on Linux.
I'm going to ask Evan Dandrea and Michael Hall from Canonical to engage with Adobe around CS and anything else in their suite that might make sense to Snap.
Cheers! @dustinkirkland
But seriously, thanks for giving it some consideration. Fingers crossed.
I would much prefer to have it without installing Wine.
I know it's not directly Ubuntu's problem, but solving this problem will go a looooong way towards developer adoption.
It's definitely worth it to try and get Adobe tools working on Linux.
Also any chance we get solid support for Wacom on there as well?
However, as far as I know there is no Linux port of these products, which really limits our ability to even start on it. Likewise the software license limits our ability to share it without Adobe's approval even if we could package it. The best thing that Canonical can do, and indeed what we are doing now, is to provide stable platform for Adobe to target and the tools to make it as easy as possible for them to do that.
Ultimately the only thing that will sway Adobe are their own customers showing a demand for those products on Ubuntu. The more they hear from Ubuntu users who want to buy their software, or people who have bought their software who want to use it on Ubuntu, the more willing they will be do make it happen. And when they're ready, Canonical will make sure that Ubuntu is an inviting and worthwhile platform for them to distribute their software on.
... that's not a suggestion for you, but we should probably set up a pirate PPA with already-cracked versions of Adobe software, ported to Linux. It's evil, but it proves that the demand exists and would allow developers to work of Linux.
If you can sell Windows applications (with WINE included) in your store, that's all the better.
I am a creative professional and dev, my father is a professional photographer and we have traditionally been a mac shop with a huge spend on their hardware.
Their latest offering is driving a lot of us to machines such as the Dell XPS 13 (which I purchased instead of a MBP).
I dearly want the same experience I get with OS X - but the one thing you are missing is a good experience with Adobe.
We've got professionals escaping the Apple ecosystem successfully to Ubuntu, but this is the one sticking point. I bet a lot of people would jump ship to your platform and give it a massive boost if you could get Adobe to put money into it. It would have more effect than any other effort in driving people towards Ubuntu.
> The best thing that Canonical can do, and indeed what we are doing now, is to provide stable platform for Adobe to target and the tools to make it as easy as possible for them to do that.
There's one more thing which you guys can perhaps do that the rest of us cannot:
Canonical is well-enough known that you may be able to get a meeting with someone at Adobe, to find out what they think would convince them to pilot a Ubuntu-compatible release of CS (or at least Photoshop and Lightroom).
I assume that it's some combination of projected sales revenue, and ease porting / maintenance / support.
If someone (perhaps Canonical) can get Adobe to throw out a number regarding how much sales revenue they'd need for a port, we could use something like Kickstarter to line up the first round of purchasers as well as demonstrate the amount of (pent up) demand.
I've always been interested in software and computers in general and, besides with the raspberry pi, I think Ubuntu has been the biggest influence on my interest in software and decision to learn programming.
A few months back I looked up my first ever forum post. https://gathering.tweakers.net/forum/list_message/28824598#2...
Asking why my PC wouldn't boot after 14 year old me stuck some components, including the HDD, in another pc. Turned out you needed something called 'drivers' to run a motherboard.
Shortly after this I ordered my first red Ubuntu live CD that you guys shipped and that was my first experience with Linux.
Anyway, open source projects that allow you to thinker with software and even break it played an important role in my life, and Ubuntu was my doorway to a decade of learning, playing and wonder about software and technology.
Running 1604 LTS now. Sad that you guys are dropping Unity for GNome but still happy with Ubuntu. I'm sure it'll work out.
Thanks, and good luck.
And that's just awesome. A few years late, but still awesome. Linux needs more Wayland-love than just Red hat/Fedora.
This one should come for free with the switch to Gnome, since it's now present in 3.24. https://www.gnome.org/news/2017/03/gnome-3-24-released/attac...
You can temporarily turn it off, which is pretty cool. Once you do the real colours seem super bright.
> This is actually a regular request of Canonical's corporate Ubuntu Desktop customers. We're generally able to meet the needs of our enterprise customers around LDAP and ActiveDirectory authentication. We'll look at what else we can do natively in the distro to improve this.
OK I get the need that some may have to integrate an UI but please don't ship a full-blown Samba/winbindd plus config generator as default.
Here's the why:
Everyone has different LDAP setups. Some use a homegrown LDAP, some use MS AD in varying versions, some use Samba as AD in varying versions - and then everyone uses a different LDAP/AD scheme (e.g. is the username attribute lowercase-able, which attribute is it mapped to, are all PCs/users in a single OU, do you want to restrict logins to specific groups, does the organization need "full" AD setup or will a plain ldap_bind be sufficient ...) and you almost always need to hand-tune the configuration for your specific setup. A GUI configurator will most likely only work OOTB for people sticking with a standard MS AD, and make problems with non-standard setups, multi-domain memberships or similar.
And: Non-enterprise users will most likely not need AD/LDAP support. Those who do should have competent admins anyhow, but what I can certainly say is that the documentation could be updated (e.g. https://wiki.ubuntuusers.de/Samba_Winbind/ only works for 12.04/14.04). I'd rather like if the documentation were improved than yet another shoddy Samba config generator that's falling out of sync with Samba more sooner than later...
(source: lost more than a few hairs wrestling with AD and LDAP)
I strongly disagree with this. Everyone with more than 2 users in their organization can benefit from AD/LDAP support, if it is easy to set up and administer.
Because... what else is viable for managing multiple user accounts across several machines? Twenty years ago, I would have said NIS (from Sun, originally called YP for 'yellowpages'). But that was horribly insecure. NIS+ was supposed to fix that, but support was never there in Linux land.
Kerberos? That seems too difficult for most small networks.
Don't get me wrong, I don't like LDAP, but there isn't anything better that I'm aware of. LDAP has some support for other applications (for example, we use it for Redmine user accounts), I don't know of anything else besides LDAP that has widespread support.
But the initial configuration was a bit of a mess, where I was going back and forth among the official docs, the Ubuntu docs, and other guides. I should write my own guide so that I can add to the confusion.
Well, even if you wanted to cloud-host authentication, what easy solution is there for Linux? Where I can create directories on a local file server and assign groups for restricted access?
Using service accounts you can then have other cloud services like Atlassian, Slack or Gitlab authenticate against the LDAP server.
Ad phone equipment: Asterisk in Docker combined with a VoIP provider (and exposing a SIP server) can work, but I have not tried this in practice. It should support standard Android and iOS SIP clients, but beware that this will drain your battery life due to permanent connections and keepalives - I don't know how easy (and supported) push notifications for calls are. Also, going from the VoIP provider through a questionable (in terms of QoS) Docker hoster to your phone will introduce a measurable latency, and the re-coding that may happen in Asterisk can also negatively affect audio quality.
When I set all this up, Docker wasn't even a thing, so it's nice to have that as an option now.
For VoIP, the hardware itself is a pain, though the open-standards software side of things is a pain too.
To deal with QoS issues, we have previously had POTS lines from AT&T plugged into a phone card on the server. So we've got that wonderful digital -> analog -> digital conversion in there.
We've recently switched to Comcast, which has a box with... analog phone ports coming out of it. So we've still got the digital -> analog -> digital conversion, plus any QoS issues on Comcast's last-mile network. Though that hasn't seemed to be a problem, so maybe they've got that figured out. And no, they didn't offer a SIP solution, at least not to us.
As you allude to, I don't see a SIP based solution for our mobile devices as viable, because of the battery drain and roaming. I really just wanted to use Skype or something similar. Who calls me on my desk phone anymore? I'll tell you who, sales people. I don't give out my desk phone number, I'd really rather you just send me an email. If you are important enough, I'll give you my mobile phone number, but that's rare.
Imagine having a box running a lan-local cache/node for a few tb of cloud-backup disk - network mounted as /home/$user and/or / - with local machine cache and regular mirroring to the cloud? With the added bonus of being open - making pure self-host an option as well as moving to other vendors?
You will always need a server. And aside from QNAP NASes (which aren't cheap) there are no "set it up and it runs" options which are free and easy to maintain.
Cheapest option, hardware wise, would be a RPi but it will melt when you try to use it as a filer. Next option is a PC, which adds at the minimum 200W of 24/7 power requirement, not exactly cheap given today's electricity prices.
Software-wise you have the option of MS Small Business Server which clocks in at 200€ but definitely requires a PC plus someone who can set it up, and a Linux variant with Samba which is free but definitely requires someone skilled.
Then there comes the maintenance - with Windows there shouldn't be a problem with regular updates, but with Linux... not so much.
The maintenance and the energy consumption of a server is what keeps small businesses off AD.
I've got just the hardware for you:
http://www.tedunangst.com/flak/post/new-home-router
https://www.newegg.com/Product/Product.aspx?Item=N82E1685620...
There are various other NUC type devices based on laptop chipsets (or you could just use an old laptop with hardware Ethernet and a large-enough hard drive... built-in battery backup!).
The software maintenance is definitely an issue, but I don't see Windows Small Business Server being any better than Linux, there's still a lot of mysterious things that can happen.
Maybe enough for the DC part (i.e. Kerberos server, LDAP server, ntpd) but not enough for a fileserver given the Pi is still 100 MBit and limited by its USB ethernet connection, as well as that it doesn't have eSATA, mSSD or any other high-performance storage option. Plus SMB/CIFS implementations are known for performance issues.
Also, a Pi is nowhere near reliable enough for running something as mission critical as an AD server. Good luck when your micro-SD card gets corrupted, e.g. due to power fluctuations. And you WILL get corruptions, especially if you have high write throughput.
> I strongly disagree with this. Everyone with more than 2 users in their organization can benefit from AD/LDAP support, if it is easy to set up and administer.
Actually anyone with either more than one user, or more than one device/computer IMNHO.
We really (still) need a sane, easy-to-set up authz/auth solution. Things have gotten a lot better - but still, nfsv4 is sort of not here, samba/cifs isn't quite secure, coda is sort abandoned, davfs isn't quite fully-featured... And so on and on.
Ssh keys are (almost) easy to use, but really hard to manage securely (everyone just ignores this, and pretend private keys won't leak) - managing a ssh CA is essentially as tricky as any other CA.
Ms realised this, and boxing up kerberos+ldap+dns (and some other bits) was their solution: Active Directory.
I'm not convinced we can't do better for a turn-key linux-first, modern solution (we have public key cryptography now, that should(?) simplify a kerberos work-a-like? Make it a standard, and bsd support should be easy, and a port to Windows/gina feasible.
I strongly believe the particulars of the solution doesn't really matter much - just make it open, with a good test suite and decent reference implementation.
Redhat is AFAIK doing great work here, as was/is Debian Edu (nee "skolelinux").
For example, if you have a laptop and a desktop, you can set up SSO and an NFS automounted home directory, so you don't need to maintain two (or N) home directories/sets of dotfiles/etc at the same time.
Good luck with unstable network connections. NFS is already enough of a PITA in a fixed office network, much less over e.g. a spotty Wifi.
Also you will need a VPN because you don't want to expose raw NFS to the Internet.
[ed: In fact I wonder if we (the community) shouldn't be able to bundle up a usable ssh server with less features, protocol 2 only, a great easy-to-use CA, maybe some bonjour/dns srv convention, and some simple db (perhaps ldap is easiest, sigh) and pair that up with ZFS for a minimal, but great, identity-of-user, identity-of-server/daemon cached/networked/encrypted data...]
That action was, IMHO, one of the biggest thank yous they could have given us.
Seems some people honestly like the look of it, how it works etc.
I however strongly dislike DEs that:
1. messing with alt-tab
2. mess with menus (I liked the idea but found the implementation to be painful)
We saw this with the intro of Gnome Shell, which fractured the community between the old Gnome UI and new UI.
If we continue to split up when something new is introduced, we are doing it wrong.
The things I mention however are things I have found to be actual problems in my workflow.
They obviously work well for others and I respect that. I hope others can respect my observation that with Mac/Unity alt-tab more keystrokes or waiting might be necessary.
It is also an objective observation that with Mac style shared menu on top of the screen in a dual monitor setup you will sometimes have to move the pointer across two screens to reach the menu, then back again to continie working.
Used to Alt+tab would simply cycle through in order of most recently used. Now they've got some functionality where shit can inject itself into that list so alt+tab and then alt+tab back and then alt+tab back to bounce between two different programs doesn't work consistently anymore.
I'm sure I just don't understand the use case for the new behavior, but it drives me bonkers.
I also hate, and I mean HAAAAAAATE when text editors autocomplete matching brackets, single/double quotes, etc. It completely fucks with my flow.
so maybe I'm just an old control freak.
I mean nowadays we somehow manage to get most hardware working 'somehow'. Sometimes it takes a few years before your sound/bluetooth/wifi chip actually does what it is supposed to do, but most of the time we find ways to make use of our hardware.
But when you are going to buy new hardware you are a bit lost. You can try to find out if there are any major problems with some hardware, search the ubuntu hardware database, but especially for new, rare or expensive hardware there is often not so much to find about. For example a few years ago I bought a 22" touchscreen for my desktop and for almost a year it somehow worked but didn't do the things it was supposed to do.
Officially supported hardware by vendors would be a great step in the right direction.
I haven't been this excited for Ubuntu since 2010.
Using ff mobile if that helps.
Edit: hallelujah! Set dom.w3c_touch_events.enabled to 0 in about:config
Nice find of the about:config setting though!
Unity is great and I love it, I don't want to lose it.
I for one however had a really strong dislike for the alt-tab behaviour as well as the shared menu.
This comes down to personal workflows. I got very frustrated dealing with the alt-tab behaviour of only showing windows when my focus is what application I need to use when I do the alt-tab. This is also the one holdover from using OS X daily, the one feature I felt was right (really, for me and probably a lot of people.)
My guess is that they've invested entire Unity vNext on Mir, and if they're dropping Mir, they'll might as well drop Unity 8. That leaves them with Unity 7, and to unfuck a decade worth of changes they've done to make it work with mainline Gnome source.
Basically lots of work to have a 6 year old product back to square one, before they can, once again, attempt to further develop it.
I'm guessing they've decided that's not worth the effort and that their time is better spent helping improve something already mature (Gnome 3).
Touché, but they could have listened to the community back when they announced Mir and Unity 8 too ;)
edit: unity8 seems to be thightly coupled to mir, although there seems to be a fork in the works to port unity8 to wayland
Oh yes. I tried all the DEs and it's by far the most pretty. I use Numix themes and it's so great. I love my pastel colored, flat icons, with brutalist window edges.
My desktop will always be Arch, however with Cinnamon and, occasionally, i3 for development.
They're redoing how widgets work in GTK+ "4". That's basically like changing HTML and having slightly different elements. Though there's a theme API, I wouldn't be surprised if some theme work is needed as a result.
See the last bits at https://blogs.gnome.org/mclasen/2017/03/31/gtk-happenings-3/ for why I think above things.
The mere thought of having to use Windows or IOS for development make me want to curl up in the corner with my blanket.
Daily I use ubuntu for my desktop, laptop, TV streamer and cloud servers. Overall my satisfaction level across all devices is at least 9/10.
Great job team Ubuntu!
I was hoping that snap or flatpak becomes universally adopted, but it seems that Redhat and Canonical are again split along political fault lines here.
We're engaging with dozens of major vendors of traditional/proprietary software about delivering their software onto Ubuntu via Snaps -- which is a new packaging format that solves many of the traditional problems associated with proprietary software working well on Linux.
...committed to getting this problem solved once and for all in Ubuntu 17.10 -- and ideally getting those fixes backported to older releases of Ubuntu."
Great news! Thanks for taking this feedback onboard.
When you do a requests.get(url), you can use the .json() method on it instead of all the json.loads([...].text). I remember doing the same for years and only discovering .json() recently, I love it.
If I had, I would have commented that the version upgrade process sucks for anyone that starts from a minimal base(like I do). If I go through the upgrade, I will end up with all the default stuff.
If I don't have thunderbird installed, don't install it for me.
In short: upgrades could be smarter, faster, better, stronger.
1. There is too much of a focus on how far Ubuntu has come and not enough focus on how far things still need to progress. I too remember the days when sleep/hibernate were a crap shot, but that was when I viewed Ubuntu as an open source alternative without much expectation. Nowadays, I see Ubuntu as a mature desktop and as such, I judge it much more harshly. Anything that doesn't work or isn't 99.99% stable is a red flag for me. So I do hope that the Ubuntu team puts more focus on making things up to date, rock solid, and super stable rather than go chase after new features. Just like a building, you need a stable foundation before building upwards.
2. There isn't a clear target audience for Ubuntu Desktop. What does Ubuntu Desktop want to be? Before it was convergence and while a very neat idea, I was never clear on who was supposed to use it. The requirements screamed high income, tech savvy end users. However, development focused on Unity, Mir, etc. with work going into features that didn't fit the target audience. For example, like the post says, HiDPI & 4K were a surprise. Why was this surprising? The group that would most likely be your early adopters and trend setters are the same exact group that would have this type of hardware. Same with trackpad, gestures, customizability, flux, root on ZFS, security, etc. All of those are used heavily by the demographic most likely to follow the news on Unity and convergence. It baffles my mind that Ubuntu's Product Management couldn't make this connection and understand what core features to build out first in Unity/Mir. Yes, these are on the sidelines now, but I really hope the Product Management team takes the time to figure out some direction.
3. At the moment, Ubuntu is at a major crossroad. Even after Mark Shuttleworth's post, this post, and all of my usual Linux news following, I don't really know where Ubuntu Desktop is going to go. Tell us what we can expect as users. Tell us when we can expect it to come. Tell us how you intend on getting there. And most importantly, tell us how we can help! Either though regular posts to various communities like the Ask HN one, or ways we can contribute actual work. Not everyone is a dev, but as an example, I used to do professional QA and yet I found it extremely difficult to find out how I can help QA things and submit useful bug reports (this isn't just Ubuntu but most open source projects). The usual "check the docs/wiki" or "submit something on the issue tracker" are not helpful. In all of my years using Linux, that Ask HN thread + this blog post was the first time I ever felt like I was heard and managed to contribute to Ubuntu. Even something as simple as periodically getting feedback from the community and telling us what you heard from us makes me feel more optimistic about Ubuntu's future.
I apologize for the rant-like nature of my comment, but hopefully this gets read and something positive comes out of it. Thanks for reading.
I agree. I was surprised that the "More QA, testing, stability, general polish" wasn't higher on the list.
How about booting ReactOS to run Windows apps? Sounds like a Frankenstein-ish solution, but...
I have seen no evidence of illicit stock grants or Apple giving direct cash to executives at adobe.
I hate to be that guy but I would like more information on this, otherwise it feels rather unsubstantiated and just paints both Apple and Adobe in a bad light for no reason.
I just have never seen any substantiation between Adobe and Apple doing this sort of thing, even when Steve was alive. This is the first time someone has even confirmed it yet alone alleged this happened. I know both companies had done things in the past that were less than savory (see that whole lawsuit about suppressing wages. Very disgraceful!)
Never this. It's been alleged for years, but never once was there evidence.
I'm sure you could make a mint here if you wanted to, if you could substantiate any of it.
We detached this subthread from https://news.ycombinator.com/item?id=14053357 and marked it off-topic.