Let me explain what recently happened while testing Azure RemoteApp.
I was put in charge in comparing RemoteApp to our Citrix cluster, feature compatibility, and cost. Now, I'm part of a university so that's "negotiated". We're also part of I2, so data ingress/egress should be free as per our site contract. (Yeah, it amounted to $5, but we were billed for it against our current enterprise agreement).
I worked with a MS Engineer to set everything up. I set cost limits to kill service if we go over $200 (past the free trial).... Well guess what? They only give emails, not kill service. Your account will still accrue no matter what. The engineer said that it could kill service. So, I had limits set to 'alert me'.
Until 2 months ago. They switched what was the Beta Portal to the main portal. Doing this eliminated even my alerts I had. The account accrued around $2800, with NO emails, No alerts, and NO questionable billing calls regarding 'non-normal computing practices'.
I'm finishing up a paper and a post-mortem regarding this incident. Obviously my university can absorb this, but the points stand:
1. There is no adequate way of controlling your bill
2. Billing calculations are done with many hours of lag-time. You don't know the zinger you just got until later.
3. There is NO fraud policy... Unless you count "Too Fucking Bad" as the policy.
The new portal is still lacking compared to the old one and they should have waited longer before pushing it IMO. I still find I need to go back to the old one for many things. Azure ML still uses the old portal.
If you need to try stuff in the future you could use BizSpark. The best way of not getting charged is not to provide payment information.
Single reason for not using cloud for personal project neither amazon nor microsoft support cost bassed monitoring and killing service. Dont why they do this though.
Using zsh instead of bash is a choice. The same more or less goes for a compiler or database. At least, we aren't seeing a situation where large numbers of major beloved projects are forcing their users to switch compiler or database.
Nearly every major Linux distribution is now moving to systemd. Regardless of its merits, this is a significant change, and a lot of us sysadmins feel like we're being forced into it. Whether you're running RedHat/Centos, Ubuntu/Debian, or Arch, systemd is coming whether you like it or not. Even if systemd's merits were undisputed, one of the things we like about Linux is choice. As it is, the merits of systemd are very much in dispute, and the choosing not to run it pretty much means moving away from these major Linux distributions entirely. Hence lots of new interest in FreeBSD.
FWIW, systemd has been pretty solid in my experience. Still, I'm glad the FreeBSD exists and is thriving without it.
To understand, you only need to read the recent posts about how systemd is effecting how commonly used userland applications work like: screen, tmux, nohup.
The systemd supporters are soon going to take away the ability to run pretty much all background processes (including using "&" in a shell) by killing those processes when your X session logs out.
This will fundamentally changes the way you administer and maintain a linux computer.
When told that this change is a bad idea, the systemd supporters said they knew better than you, and they are doing this to make the desktop UI better.
This is one small example why they invoke "hate".
They make a decisions like that every day that dramatically effect the entire linux platform.
If I can't run "nohup" or "screen" or "sh &" to do my job anymore, then that forces me to use some other OS/distro that does not have systemd installed as the default.
> The systemd supporters are soon going to take away the ability to run pretty much all background processes (including using "&" in a shell) by killing those processes when your X session logs out.
Really? That is your takeaway from the recent changes?
What actually happened was that systemd developers changed the default setting (from off to on) for an optional feature in logind that has existed for 5 years.
This setting was promptly reverted back to off by default in Debian, and probably most distributions that are shipping a bleeding edge version of systemd.
No one is taking away anything from anyone, which unfortunately includes your ability to spread FUD about things that you don't understand.
My takeaway from that change was that (1) the systemd team was perfectly willing to break userspace (existing programs, scripts, and even habits), and (2) that they wanted to put the onus of dealing with their decisions on third parties (e.g., the Github issue for tmux).
"The systemd supporters are soon going to take away the ability to run pretty much all background processes (including using "&" in a shell) by killing those processes when your X session logs out."
WUT?
(goes and downloads FreeBSD...)
I've been a Linux user since 1993 and SystemV init was something definitely in need of replacement. But this was not even close to the most pressing problem in the Linux ecosystem. The most pressing problems were and are things like the clunkiness of package management, the inadequacy of the root/userland permission model, and general user experience and UI issues. Systemd is not addressing any of that and may actually be making some of those problems worse.
After using systemd a bit, I've become a hater too. It's a clean slate reboot of init and yet it's somehow managed to be more arcane and confusing than sysV-init. That's an accomplishment, but not an admirable one. It tries to do way too many things at once in one vertically integrated system, has an arcane confusing non-intuitive syntax and configuration scheme, and just generally feels "enterprise" in the "over-engineered mess" pejorative sense of the term. Whenever I use it I find myself thinking "why would you do it like that?" and "who wanted that?" over and over again. It feels like the sort of system that's deliberately engineered for obtuseness so high priced consultants can be paid to operate it. Maybe it is.
Unfortunately FreeBSD's init system seems at first glance to be even more primitive than Linux's old sysV-init. Checking out the docs it looks like a trip back to the 1970s.
Is service management with a simple graph of dependencies really that hard? Come on. Good programmers solve these kinds of problems all the time on a much larger scale. We've got OSS hackers building distributed systems, fault tolerant databases, cryptocurrency, and 'permanent decentralized web' protocols and we can't solve init?
> Checking out the docs it looks like a trip back to the 1970s.
The BSD world never adopted System 5 init, and can indeed trace its mechanism back to Version 7. Ironically, however, that init has outlived both System 5 init and its van Smoorenburg clone.
Reasonably we can conclude that we are in fact forced to use systemd.
if you want to use a modern production ready distro for servers you cannot look further than: ubuntu, debian, RHEL/CentOS, and probably SuSE (although declining).
If you're an american company you're very likely using CentOS already and if you're a European company you're very likely using debian already, and there is little wiggle room there.
So, yes, my standards body ensures that systemd is inflicted on my systems and it's a lot more hassle to move away from debian right now than to embrace systemd for all it's warts.
That "death threat" was a bad joke made on a IRC channel after hours, after several on the channel had spent the day trying to debug some issues caused by changes in the most recent systemd release at the time.
On top of that he is a loudmouth and head of a controversial project, that is basically a big neon sign these days for attracting the "gamergate" hive.
FreeBSD is so very much worth taking a look at. Hardware support is not on Linux’s level, so it’s not necessarily an endeavor I’d recommend for desktop use, at least as a first 'nix experience, even with the super nice ZFS integration in PC-BSD.
But if you’re at all frustrated by any aspect of Linux in server use, it’s worth having a peek at FreeBSD. And I’m saying this as a person who doesn’t really have much business talking about tools like dtrace or even jails. But I will argue that it’s the increasing wtf:ness of Linux that has held me back from wanting to become a more competent admin and more focused on IT work in my career. Blame the system, right?
As a reluctant IT person and "advanced beginner" sysadmin, I was inspired to look into FreeBSD this spring. The final push had a lot to do with that massive, remotely exploitable glibc vulnerability (CVE-2015-7547), when the potential consequences of Linux monoculture started to really dawn on me.
First thing I did was to migrate a couple of my Tor relay nodes to FreeBSD (instructions here: https://torbsd.github.io/ ). Whether my handful of <10 Mbit/s middle relays are real workloads or not is debatable, but it’s stuff I have a sense of duty about, especially with regards to doing basic security due diligence. Tor has a direct impact on real people doing real things, but it's not like these boxes keep me from working if they're down for a week, so it’s a good place to learn.
After ten years on Debian and Ubuntu for server stuff, FreeBSD is quite refreshing. There's really a lot to love: human readable userland, man pages and scripts, the simplicity of throwing basic ipfw rules in /etc/rc.conf etc.
Whereas stuff tends to "just work" on Debian (including automatic restarts of services after package installs), one needs to read the manual on FreeBSD. But everything feels like less of a pain to learn. And to be clear, the system doesn’t feel like a "tinker or GTFO" kit like Gentoo or Arch, starting with the installation process.
After looking quickly at pf for more advanced networking stuff, I feel like I’ve been duped into believing that I hate networking, when it’s really the syntax of Linux’s iptables that is at fault.
Another thing I definitely need is in-place upgrades, without the need to boot from media (like OpenBSD and NetBSD still seem to require). ‘freebsd-update’ seems to be stable nowadays. For the base system, FreeBSD seems to be moving towards a proper LTS model, where one is encouraged to stay on top of point releases. https://news.ycombinator.com/item?id=8991960
For third party software, packages seem to make a whole lot more sense than my expectations. I had heard that FreeBSD only recompiles all their packages every few weeks, but nowadays, it’s every three days or so. I have used ports on my Tor relays in order to be able to install security patches immediately.
As a virtualization platform, I suppose Linux’s KVM remains a lot more mature and well supported. But the bhyve hypervisor seems to be coming along nicely. Before long FreeBSD might become a good virtualization platform. Personally, I can’t wait to see something like FreeNAS becoming a virtualization appliance, like the one you’d get with Proxmox or those QNAP prosumer file servers.
From what I’ve seen so far, it seems increasingly frustrating that BSD didn’t become the major free 'nix platform back in the day.
>> From what I’ve seen so far, it seems increasingly frustrating that BSD didn’t become the major free 'nix platform back in the day.
I remember when FreeBSD was considered to be more mature than Linux for server use. What made Linux more exciting than FreeBSD? Why did FreeBSD lose ground?
The problems, for me, were:
- apps developed specifically for Linux. The shim wasn't 100%.
- Hardware support. This wasn't too bad, but I always had to take it into consideration.
- Virtualization. This was the killer for me. Yes, jails are fantastic, if your entire workload ran on FBSD. But if you needed even one Windows/Linux instance, for any reason, you needed another physical machine. With Windows and Linux I could consolidate everything into a single machine.
Things have improved a lot, and I may try it out again, but unfortunately the mindshare is all Linux now.
It took a long time for FreeBSD to support MS-DOS partitioning, so for a long time you couldn't dual-boot between Windows and FreeBSD without buying a second hard disk. So kids getting started tended to run Linux instead of FreeBSD, and they stuck with what they knew.
> From what I’ve seen so far, it seems increasingly frustrating that BSD didn’t become the major free 'nix platform back in the day.
The thing is, had BSD not had the unfortunate legal incident and had been adopted as the major free 'nix platform, then it would look very different than it does today. There would have been more and different developers, different backers, different agendas. Different small influences played out over 30 years.
FreeBSD has always had a centralized development model that inoculates it against the kind of Linux churn that you see in terms of "different developers, different backers, different agendas".
Either you produce a careful, generalized solution, or it's rejected.
Yes, but in the presented hypothetical and over such a long time, the fact that it was able to maintain this in its current underdog role does not mean it would have been able to so as the main adopted 'nix.
I'm not sure it's fait acompli (I could be convinced!).
My thinking is: there's no requirement that a project not only accept just about any half-baked feature patch, but actually design an entire version control system to optimize for that use-case.
As a single data point, I'm someone who recently gave up on Linux and moved over to the BSDs. Not that the BSDs were new to me, but I've given up on Linux for servers, and Debian specifically, precisely because of systemd.
I'm tempted to do the same myself, but man, how can you live without apt-get and dpkg? I haven't looked at FreeBSD for ages; in OpenBSD packaging and patching is quite a pain, and this is holding me back a bit.
To be honest, I'd rate pkg-ng higher than apt and dpkg these days. It's faster, cleaner, and uses an SQLite database as the backend, which allows for much more interesting queries for figuring out system state. For the base system, FreeBSD has an in-place binary updating system called freebsd-update that works rather well. I'd definitely encourage you to try FreeBSD, it has a beautiful amount of cleanliness that's missing from current Linux distros.
FreeBSD has a binary package manager (pkgng) that should feel much like apt. The ports tree still exists if you want to customize and build from source, but in general you should be fine just using pkg.
There's no "should" about it. It does feel like APT. (-:
I invoke aptitude install on Debian and pkg install on FreeBSD/PC-BSD. dpkg -b stage/ target/ on Debian; pkg create -r stage/ -o target/ on FreeBSD/PC-BSD.
Bear in mind, of course, that the SVID package management is a clear precursor to both of them.
Makes no sense to me at all, what systemd does brings the Linux ecosystem closer to what FreeBSD offers, a standardization of base components, which is what FreeBSD (and of course the other BSD's) are doing, but on a whole OS level.
So if you dislike the tight coupling of components in systemd, why on earth would you go to FreeBSD which is a whole OS developed with tight coupling ?
So I think this is nonsense, as I see it, it's just FreeBSD advocates trying to play off the systemd controversy in Linux land.
FreeBSD/*BSD traditionally maintains userland and kernel together. The userland is also BSD licenced so using GNU is not possible so there is need to maintain these tools. But mostly it's taken from a shared upstream with some specific patches. There are seldom new components that introduce huge changes. There is also mostly a single community that decides on changes. This has led to splits in the past but usually things are consensual.
systemd as a project was/is mostly driven by Red Hat and kind of praised itself into distributions due to eating udev and that would have required a fork (Gentoo did that with eudev). Debian almost self destructed in the discussions and it's mostly unrelated with the kernel. They tried to push kdbus but this was denied. So there was some split between distribution developers (systemd made a lot of stuff easier and was the new upstream for must-have-components) and users (never change a running system) about that. This has caused lot's of nasty fallout on the internet - mostly from the users that were opposed. But both sides kind of heated the debates.
> So if you dislike the tight coupling of components in systemd, why on earth would you go to FreeBSD which is a whole OS developed with tight coupling ?
Source lying in the same git repository is not tight coupling. Depending on dbus,journald,logind kind of is, but systemd is not really tightly coupled it's more like there are components that can be used and software has to adapt to use it (GNOME, kwin migrated to logind on Linux), tmux and screen likely will adapt to the user sessions. So you kind of have to use it on Linux, to not be an outsider and run unmodified upstream tools.
I guess tight coupling is that you have to use the whole systemd package and can't just pick e.g. logind or the udev parts on your system. These won't work without everything else. So it's far more coupled than FreeBSD at the moment.
FreeBSD maintains only the typical POSIX/UNIX userland. No one tells you what to do and most userland is pluggable - e.g. they have a patched OpenSSH and Sendmail as default - this can be disabled with 2 lines and you can install OpenSSH and Postfix and everything will work fine. You can also exchange syslog or ditch cron and run runit and runwhen instead. Everything will still work after that. You need to know what are you doing through but that's kind of the mindset of using BSD.
It's almost impossible to rip out e.g. journald or dbus of a systemd distribution. It's not necessarily bad it's just a different idea.
> So I think this is nonsense, as I see it, it's just FreeBSD advocates trying to play off the systemd controversy in Linux land.
Actually I've never saw this from FreeBSD devs - there might be some fanbois, like everywhere but usually it's a more professional and calmer community. FreeBSD is and was always quite popular on HN there are a few core members here as well. FreeBSD has a lot of merits that Linux lacks or does slightly different. Clang, DTrace, ZFS, Jails, ByHyve... so it's an interesting topic to talk about.
I guess most FreeBSD users don't need to badmouth Linux and even FreeBSD is looking into getting a new init based on launchd or some alternative - not sure what the current status is - because dependency resolution and reaction to events becomes important. Unit files are also a good idea that will spread. There is also SVC from Solaris that inspired systemd (amongst others) so there is nothing spectacular unique or new that systemd offers in regards to init.
Most criticism against systemd also has nothing to do with the init aspect but with policy choices and defaults from the maintainers e.g. arbitrary new limits or changing default behavior or rewriting old tools in a manner that is disliked by some. Recently Ubuntu decided to include the systemd-resolved resolver and that caused some fallout due to certain assumptions from the devs.
So systemd kind of changes the whole Linux ecosystem - IMHO in an honest attempt to improve it - and this usually causes some breakage even if it's for the better and if you just want to run your Unix and don't need the features you not really enjoy the ride. E.g. because the most events your server gets is a new IPv6 prefix once every 2 years you don't just need all the new bells and whistles. A lot of experienced devs and sysadmins also voiced conceptional and design complaints but I'm not able to judge that really. Some of it looks very reasonable.
TL;DR systemd is not just init - it changes Linux and causes fallout - FreeBSD was always popular and it's getting attractive for servers due to these changes.
>But mostly it's taken from a shared upstream with some specific patches.
Is it, that's not the impression I've gotten of the BSD's development, where is this shared upstream located ?
>Source lying in the same git repository is not tight coupling.
No, but the components are written to take advantage of eachother and make use of the features of the underlying system, this is true for both systemd which makes direct use of Linux specific features, and the FreeBSD components which makes use of FreeBSD specific features like Jail.
>No one tells you what to do and most userland is pluggable
The FreeBSD devs only support the components they ship with, they offer no workarounds for anyone wanting to run something else, if you do you are on your own. I fail to see how this is in any way different when it comes to systemd dependency.
>arbitrary new limits or changing default behavior or rewriting old tools in a manner that is disliked by some.
This will always be the case no matter what, whenever you change old patterns some people will not want to change, not anything wrong with that, it's just a fact of life.
>A lot of experienced devs and sysadmins also voiced conceptional and design complaints but I'm not able to judge that really. Some of it looks very reasonable.
I'm not overly fond of systemd, I think it's a step in the right direction, but I hardly think it's the 'ultimate solution', I fully expect it to be superceded by something better in the future, but of course that solution, whatever it is, will also suffer the same controversy as systemd has suffered now, it's just the nature of the game.
>TL;DR systemd is not just init - it changes Linux and causes fallout - FreeBSD was always popular and it's getting attractive for servers due to these changes.
Again, I don't agree with this conclusion, I don't think systemd is driving Linux users towards FreeBSD, to Gentoo perhaps or any other Linux distro which provides the flexibility and support of components which systemd and FreeBSD does not.
> Is it, that's not the impression I've gotten of the BSD's development, where is this shared upstream located ?
Not everything but there is OpenZFS, similiar for DTrace, e.g. DNS is unbound that is included, same for OpenSSL and stuff like that. Sure there are specific Unix tools that have their own implementation. The *BSDs also share code between them, so you have some OpenBSD and NetBSD code in FreeBSD and vice versa.
> No, but the components are written to take advantage of eachother and make use of the features of the underlying system, this is true for both systemd which makes direct use of Linux specific features, and the FreeBSD components which makes use of FreeBSD specific features like Jail.
Well there is a flag for jail processes in ps and a jail utility but that's about it. Everything else is pretty much BSD and POSIX, small and clean. Or what exactly do you mean?
> The FreeBSD devs only support the components they ship with, they offer no workarounds for anyone wanting to run something else, if you do you are on your own. I fail to see how this is in any way different when it comes to systemd dependency.
Not really. Most examples I gave are documented in the handbook and it's not really about supported but it's so simple that it comes down to deactivating something in rc.conf and activating something else. Most scripts are thoroughly documented and not much magic is happening. Like using Postfix instead of Sendmail. Some stuff is not officially supported like compiling base with LibreSSL that's worked on but you usually don't came across huge hurdles or complexity - and if so you can mostly figure it out.
> This will always be the case no matter what, whenever you change old patterns some people will not want to change, not anything wrong with that, it's just a fact of life.
I guess there is a fundamental difference in attitude. Change for the sake of change is frowned upon, there needs to be good reasoning and benefit in changing something.
Killing background processes after leaving the session by default or trying to prevent fork-bombs for all with some arbitrary task limit is something that is a behavoir change and would likely appear in bold in RELNOTES if ever adopted.
> I'm not overly fond of systemd, I think it's a step in the right direction, but I hardly think it's the 'ultimate solution', I fully expect it to be superceded by something better in the future, but of course that solution, whatever it is, will also suffer the same controversy as systemd has suffered now, it's just the nature of the game.
So it's opinionated and some people have a different opinion.
> Again, I don't agree with this conclusion, I don't think systemd is driving Linux users towards FreeBSD, to Gentoo perhaps
You're not an sysadmin or are you? There seems to some some odd split between sysadmins and other users of Linux. Deploying FreeBSD is much easier and less work as handling Gentoo. You can basically survive with regular freebsd-update and pkg update if don't do anything fancy.
> or any other Linux distro which provides the flexibility and support of components which systemd and FreeBSD does not.
Sure there are lots of alternatives - alpine, void linux.
I don't mind systemd - I think it's not exactly elegant but it solves real problems for a lot of people. I just think it's difficult to compare FreeBSD to systemd as you did.
>Not everything but there is OpenZFS, similiar for DTrace, e.g. DNS is unbound that is included, same for OpenSSL and stuff like that.
Eeh ?
OpenZFS is not a BSD upstream project in any way shape or form, heck it did not even originate in the BSD's, it came from Solaris, same with DTrace.
Also AFAIK only FreeBSD of the BSD's support ZFS and DTrace ?
OpenSSL, same here, how is this a BSD upstream project in any shape or form ?
>The *BSDs also share code between them
Very little from what I can tell, unless you count projects which did not originate from one of the BSD's. Anything you can point me to ?
>but it's so simple that it comes down to deactivating something in rc.conf and activating something else.
Based upon your distro choice, this isn't harder in Linux either, nothing you need to venture over to FreeBSD for.
>Killing background processes after leaving the session by default...
Well there is quite a difference here as systemd as a project compared to FreeBSD does not ship binaries, they ship a tarball which is then configured, compiled and deployed by a distro, which in turn decides what options to use as default for their userbase.
Whatever default systemd chooses, it will be right for some and wrong for others, but each distro will most likely choose the option best suited for their userbase (or face complaints).
>there needs to be good reasoning and benefit in changing something.
But who decides what is 'good reasoning' ? That's just a nonsense statement, with practically any change, some people will think it's good reasoning, and some will think it's bad reasoning.
> OpenZFS, [...] OpenSSL is not a BSD upstream project in anyhow is this a BSD upstream project in any shape or form
Upstream as in it's included in the distribution but not primarily developed there. I thought that is the correct way to specify something that you use but that is from somewhere else? OpenZFS grew out of OpenSolaris and is now used from ZFS on Linux, illumos (SmartOS and others) and FreeBSD. Same fore DTrace.
> Very little from what I can tell, unless you count projects which did not originate from one of the BSD's. Anything you can point me to ?
Just a quick Ctrl+F on the release notes https://www.freebsd.org/releases/10.0R/relnotes.html#new - make from NetBSD, a driver from OpenBSD. I guess there is more flow for bugfixes and patches. It's not so uncommon afaik but I'm not sure.
> Based upon your distro choice, this isn't harder in Linux either, nothing you need to venture over to FreeBSD for.
I've never claimed that? It's hard for systemd components. It's also clear that Linux is clearly better fitted or the only choice for a lot of use cases due to hardware and software constrains. I don't mind Linux :)
> Well there is quite a difference here as systemd as a project compared to FreeBSD does not ship binaries, they ship a tarball which is then configured, compiled and deployed by a distro, which in turn decides what options to use as default for their userbase.
IMHO defaults matter a lot. Sure, I can also turn it off with a small edit but then I need to remember the machines where it's on or off and I'm often don't have root. The problems due to the task limit are also not so great and this is in Ubuntu 16.04: https://news.ycombinator.com/item?id=11675129
It's nice to have release notes that are reliable and and predictable behavior. It's a different attitude.
> Whatever default systemd chooses, it will be right for some and wrong for others, but each distro will most likely choose the option best suited for their userbase (or face complaints).
Yeah, not all agree with this approach. This is is totally understandable from the point of systemd as they want to move fast and get stuff done but usually that means that you don't know what to expect when you login somehwere - you basically have to lookup systemd defaults related to the distro release or worse patch-version. If you just want to deploy something and make it run stable and fast it's a PITA. Often you don't have control over the distribution.
> But who decides what is 'good reasoning' ? That's just a nonsense statement, with practically any change, some people will think it's good reasoning, and some will think it's bad reasoning.
How is this a nonsense statement? Philosophers thought about this for thousands of years, it's the foundation of science. How about something you are able to reason about easily that is fully understandable and easily to modify, composable and lacks hidden complexity and side effects?
Sure you'd write software for nuclear power plants with other constraints than a personal website. In the former case you should focus on maintainability and ease of understanding and correctness - while in the second case the primary goal is likely to get it done as fast as possible to your personal liking.
I think operating systems are kind of similar. You can't always throw everything in VMs or containers that can malfunction. Sometimes it need to work. Surprises are bad.
Due to the changes surprises happen with systemd - that's the unavoidable problem.
> Nope, I'm a developer.
That's a different perspective and I'm sure that you experience systemd as a godsend for a lot of stuff that eases your life. Just different priorities. On the desktop I'm also happy to have some systemd based system that does the magic for me but with servers a lot of people have different expectations.
>Upstream as in it's included in the distribution but not primarily developed there.
Your claim was that most of the BSD's was from a shared upstream, with a few patches, and then listed things like OpenZFS and DTrace as examples, which again to my knowledge is only supported on FreeBSD of the BSD's... ?
>make from NetBSD, a driver from OpenBSD.
And lots of drivers from Linux as well, heck given that all but FreeBSD default to using GCC, I'd guess they (the different BSD flavors) have more code (as in lines) in common with a typical Linux distro than with eachother.
>IMHO defaults matter a lot. Sure, I can also turn it off with a small edit but then I need to remember the machines where it's on or off and I'm often don't have root.
But again it's the distros who choose the actual defaults you as a user will have, your distro is your actual upstream, not the systemd project.
>defaults related to the distro release...
Which is the same with differences between the BSD's, or different OS'es in general, which is what a distro is, a set of components combined in to an operating system.
>How is this a nonsense statement?
Because there is no objective definition on what constitutes as 'good reasoning' in this context, it's all subjective, depending on your needs/preferences.
>and I'm sure that you experience systemd as a godsend for a lot of stuff that eases your life.
Actually the impact for me has been minimal, slightly faster boot, slightly faster shutdown, and easier log examination.
> But again it's the distros who choose the actual defaults you as a user will have, your distro is your actual upstream, not the systemd project.
This is a dichotomy that does not exist in practice. It's the same people "upstream" as "downstream". In the cases of Debian, Ubuntu, and Arch, for examples, the distribution's listed maintainers are also systemd developers.
Not that one should take this as singular to systemd. The idea that there's some form of Chinese wall between a package's own developers and its maintainers at the various distributions is not reality in a number of places. Take mediawiki, for example. The person seeking to package it up and be its maintainer for Debian in 2016 is a Wikimedia Foundation software engineer.
>This is a dichotomy that does not exist in practice. It's the same people "upstream" as "downstream".
I believe that's nonsense. Out of all the software being packaged in all the distros out there, I would say only a very small amount is actually being packaged by people who are also upstream developers, there are LOTS of distros and LOTS and LOTS of packages out there.
>In the cases of Debian, Ubuntu, and Arch, for examples, the distribution's listed maintainers are also systemd developers.
systemd is a quite large project, some 250+ different committers, and from what I've read, neither Debian, Ubuntu or Arch will use the new default of shutting down user processes upon logout, despite them having upstream systemd developers responsible for the distro packaging.
> This is a dichotomy that does not exist in practice. It's the same people "upstream" as "downstream". In the cases of Debian, Ubuntu, and Arch, for examples, the distribution's listed maintainers are also systemd developers.
> I believe that's nonsense.
You can believe that if you like, but yours isn't a belief in any way founded in fact. Tomasz Torcz's 2014 lists of the top systemd developers includes the Debian, Ubuntu, and Arch maintainers.
> tmux and screen likely will adapt to the user sessions.
This would be a shame, because: (a) Nicholas Marriott has a good point now and had a good point 5 years ago; and (b) this is a logind bug, a mechanism that is broken when turned on, actually fixing which (rather than merely turning the setting back off, again, only to go around the same daft loop in another few years) involves no code changes at all to wget, deluged, emacs, screen, tmux, nohup, or any of the other programs that are affected by this.
Don't be so sure - I used to be an Arch guy because I loved their dead simple config, everything in rc.conf, etc. One of the big pushes for arch early on was that it was BSD-like.
Arch progressively lost this feature and was one of the first distros to adopt systemd which was the last nail in Arch's coffin. When their docs suggested I manually write a unit file to configure networking rather than having 1 line in rc.conf, I was done.
My move was to go to FreeBSD. I feel like I'm right back to what I liked about Arch originally. So yeah, I'm sure some people are well served by making this move.
Ha, I did exactly the same thing. FreeBSD is well-organized and generally makes sense. It stays out of the way and just works.
BSD documentation culture is also second-to-none. Seriously, the manual for every BSD is incredible.
FreeBSD's cousin DragonFlyBSD is also (IMO) doing some of the most interesting research in Unix-like OSes right now. It's a sort of hybrid of FreeBSD and Plan9, with a cutting-edge-and-more-stable-than-btrfs filesystem.
Total anecdata, but the usual amount of HN comments on how this and that "just works" in Arch, seems to have dropped recently. It's still #9 on Distrowatch (I'm pretty sure at one point it was in the top 5), so it's not disbanded or anything.
I could see how the core Arch users would despise systemd anyway. For all protestations to the contrary, Arch is pretty hardcore ("all upstream all the time! Configure everything yourself!"). Hardcore old-hat sysadmins are the ones most affected by systemd reinventing the init wheel.
>BSD is for people who love Unix, Linux is for people who hate Microsoft.
OpenBSD is for people who love the UNIX equivalent of Dwarf Fortress. I call it a full contact OS because of what will happen to you upon asking an easily googled question.
The dragonflybsd community is great. When I was experimenting with it, their freenode channel was super helpful, often with Matt himself answering questions. I ran into a bug after an upgrade and he had a patch up in like an hour.
I've been deploying my stuff in linux containers recently, and I really like that flow. I really hope something like Jetpack (https://github.com/3ofcoins/jetpack) can eventually provide a solid OCI implementation on top of jails and hammer (not sure what containers demand of a filesystem, I know jetpack is currently focused on ZFS).
If you have a job to do I'd rather use FreeBSD but unfortunately lot's of support for popular software is missing.
I thought about using it for a big Hadoop cluster due to ZFS and jails but at that time there was no recent Hadoop port and some tinkering is often required to get rid of glibc specifics or dependencies on Linux only APIs (epoll and stuff like that)
However I guess even with a good working port it's difficult to convince a team that only uses Linux for like their whole life. We somehow decided on btrfs at that time (around Linux 3.16) and I've was busy reading stacktraces and debugging hangups for a while... Hadoop somehow also triggered some bug in transparent hugepages...
So yes, Linux is mostly plug'n'play if you need a VM for a Wordpress but IMHO digging into Linux internals can be fare more challenging than grasping FreeBSD - I guess if I had the task again I'd definitely would go with FreeBSD.
It bothers me that too much is Linux-only (or worse: Linux+x86-only) these days, making assumptions about the system that we just couldn't (and were forced to do it right) in the IRIX/Solaris/AIX days.
As someone who uses Linux, OSX, Homebrew (why, oh why?) and MacPorts daily, I can readily say we don't make our software as easily portable as we used to.
I have to agree with this. I used to stick to Ubuntu, but now I'm starting to look around.
Now that I see FreeBSD on AWS, Digital Ocean, etc. I'm seriously considering that. I spun up a droplet yesterday just to check it out. Everything worked fine, but I cannot justify the switch yet. I'm planning on really testing it out in a few months. Til then I'll hang on to LTS.
Microsoft is large enough that there are good and bad parts, but still they're not extending OS support on Azure out of goodwill. It's a cloud provider, so naturally they want to at least support the same stuff AWS does.
He used launchd as his example since opinions backed by code have always had more weight in BSD communities. This led to all the systemd comparisons. But in reality, you can ignore all of that.
What his talk was about was a keynote about the ongoing paradigm shift from 'big unix iron' to ever more ephemereal OS instances that move, live, change and die faster and more rapidly. This conflicts with a number of UNIX designs where boottime matters and sets things in stone for the remainder of the current run.
These are problems that need addressing; people need to think about them and come up with ideas and solutions. The project and the community needs to decide to tackle these issues or declare them out of scope. In that context systemd is an interesting case study, since some of it tries to solve similar problems to provide a more dynamic and more MP-friendly runtime. The actually used software to accomplish this is secondary (while acknowledging that everybody has of course personal favourites and preferences).
Well he developed launchd for OSX, that was a partial inspiration for Poettering to develop the init part of systemd. Note the launchd stops well short of the scope creep that systemd has engaged in.
That said i think Hubbard has given up on getting one of the existing BSDs to adopt launchd. Instead he has forked Freebsd into Nextbsd and added launchd there.
Note the difference between that and how systemd is crawling its way into every big distro out there by absorbing (udev) or replacing (consolekit) existing, loosely coupled, projects.
That's actually pretty neat. I don't have any real complaints about systemd, but every alternative I've looked at is more painful to use for service management. No longer having to hack together init scripts has been wonderful for me, it took a 10 line unit file to get YouTrack configured as a proper service on my CentOS 7 VM - I used to run JetBrains teamware products on Windows just because dealing with custom init scripts was such a pain in the ass.
> it took a 10 line unit file to get YouTrack configured as a proper service on my CentOS 7 VM
If you did it the way that other people have done it, wrapping youtrack.sh start and youtrack.sh stop in a systemd service unit, with a sprinkling of erroneous Type=forking to get around the fact that that ends up running the Java process as a quickly orphaned grandchild of where systemd expects the daemon to be, and with log output explicitly redirected away from where service management could handle it into an ever-growing private log file under /usr ... then you have entered systemd House of Horror territory. "proper" is not really the word.
I initially tried the Type=forking method, but systemd kept yelling at me (as it should have) because it doesn't really fork correctly. I actually just run the service in simple mode with a launcher script that contains this abomination of a command:
Just remember to do things the daemontools way, and chain to the final daemon binary from that script with the shell's exec command, and systemd should be happy.
I don't understand the appeal of Docker on FreeBSD. The native jails on FreeBSD basically do the same thing by default (spin up a jail, execute a command, exit) unless you explicitly tell them to persist (at that point, they behave more like LXC than Docker).
Except FreeBSD jails are way easier to manage in terms of storage and networking.
Although I disagree with the need for Docker on FreeBSD, I actually agree with your statement -- Docker is such a popular thing right now that not supporting it will probably keep some people from trying FreeBSD.
On the other hand, the BSDs in general are communities where the Eternal September seems to be quieter than elsewhere. They're rock-solid and technically brilliant, but they're just not 'mainstream,' and not really trying to be. It bugs me sometimes, too, but I just don't think that getting more popular is what most people in that community are interested in.
So they can screw you over with "Unknown until later" bills, complete lack of being able to control your funds and services, and what I call "Comcast Bills" (AKA: pay what we tell you and GTFO).
Just read my previous comment (or the top one of this story). Doesn't even matter if you're an enterprise with a site license of 150k people.
I am always a bit surprised by comments that give Microsoft a bad reputation no matter what it does.
The computer science field has always been "ruled" by ideas and philosophies, but in the end a company is a company, and the ultimate goal of a company is to make money.
It isn't weird or evil that Microsoft is trying to make money using whatever mean it can use.
By the way, it's crystal clear that a considerable Microsoft is pivoting to become a cloud provider and in that sense the most obvious thing to do is to provide developers with all of the tools they might need.
Kudos to Microsoft for being able to perform such a direction change.
Plus consider that competition usually means lower prices for customers.. We should be happy that new players are diving into the cloud business.
Well, I don't know your age but a lot of us grew up during the 1990s and early 2000s and experienced Microsoft's bully behavior first hand while we were trying to make Linux[1], Free Software and Open Source more popular.
That kind of trust is hard to win back.
It may be childish but I've been enjoying Microsoft's fade into irrelevance the last decade.
How exactly has Microsoft "faded into irrelevance"?
Various versions of Windows are used on probably 90% or more of desktops and laptops, in both home and business settings. It still sees widespread server use.
Word, Excel, PowerPoint and Outlook are widely used.
SQL Server is quite common within many enterprises.
Azure is a major player, and is seeing more and more adoption.
The porting of .NET to Linux and OS X is making Microsoft's development technologies available to a wider audience.
The Xbox brand of consoles is quite popular.
Microsoft has numerous offerings, across a range of sectors, that have huge uptake and are quite successful. I don't think that "irrelevance" is the way to describe Microsoft or their products.
Since I seem to have ruffled some feathers with my statement: compared to how dominant Microsoft used to be, they're now just one of the companies offering a certain product in many markets. This is a good thing.
"Irrelevance" was perhaps hyperbole but if you compare it to their past, well...
I'd say the only product they have left where one doesn't have much of a choice (in business mostly) but to use it is the Office line and even that is debatable nowadays.
So while many businesses would trade with Microsoft's position in a blink, they are not the unavoidable powerhouse they used to be.
The difference with the past is that the landscape expanded. We now have web and mobile, two areas where MS failed miserably and the companies that emerged are equal or larger in size than Microsoft. Other than that they're still the behemoth they used to be. Given that most of us here make our living from the web we think that Microsoft is irrelevant, which is far from true.
If you engage with corporate America at all, you'll find that Microsoft is not only relevant, but immutably ingrained into the DNA of the company. Office, SharePoint and SQL Server are not to be trifled with in corporate America - do not make the mistake of discounting their relevance or significance in how work gets done in the VAST majority of companies with >1,000 employees here.
> Microsoft is not only relevant, but immutably ingrained into the DNA of the company.
For the current generation, perhaps. There was a time Microsoft reigned pretty much alone, where there were no other viable options. During that time, Microsoft defined what a PC was and dictated what everything around one looked like.
That's not the case anymore, and it hasn't been for quite some time. Where you find Microsoft is much like where you expected IBM mainframes to be in the 90's - in high-inertia systems. It's too difficult (and, frankly, not that cost-effective) to convert your documents to other formats or to cloud-based office apps. What you gain from it is not enough. It's too difficult to move your AD users. It's too difficult to port your apps to use other databases after you fell for writing stored procedures in TSQL for everything.
Mainframes are not dead yet and will stay around for a while. Microsoft will stay around for some time too, but it will never again dictate what a computer is.
After all, if you look at a chicken really close, you'll realize dinosaurs are still around too.
I get that some of the developers and enthusiasts that were around professionally during that period would be untrusting of MS (rightfully so), but to say they've been fading into irrelevance when they still hold the vast majority of the marketshare in desktop/laptop OS? To me, that just sounds like whining of a bitter fanboy.
It's far from irrelevance, but you can't deny they've lost a lot from where they were. Their dominance over the desktop/laptop OS market is still real, but the market is shrinking in favor of other form factors. In their other markets, they're attacked from every side.
Microsoft antagonists tend to generate very fuzzy and imprecise opinions. They are akin to conspiracy theorist, and like the religious you can almost never narrow them down to a specific objective thing.
You will argue with concrete-objective facts and they will reply with generalities and feelings.
That might be because the "antagonists" are motivated by something more complex than whatever bulletpoint you're focused on... like the concept of free software. Try to think of an elevator pitch for it, now imagine how that would hold up in an adversarial debate where your interlocutor likens you to a "conspiracy theorist" or "the religious".
> Its a pattern -> learn to recognise it.
Yes, you've perfectly demonstrated the association fallacy, learn to recognize it.
If you point out to a football team supporter, that what constitutes their team is always in flux. Player's change, managers change, staffs change, owners change, uniforms change. Sometimes even grounds change and names even change <- objective facts!
You will rarely be able to dimmish that persons passion and feeling for that team or convince them that the other team isn't as bad as they feel it is.
I don't think any further examples of the association fallacy are necessary. Isn't it obvious that such analogies are debate tools, not useful in actual conversation? Do you expect someone to further the conversation about FreeBSD preference by defending sports fans?
Nearly all of those people have left Microsoft, more often than not for Amazon and Google when they've stayed in industry, so if you are unhappy with that behavior, then you know the right firms to take it out on.
I agree with your statement. I wouldn't trust MS to run FreeBSD on their hardware at all. What if they throttle the performance of FreeBSD without you ever knowing it? Embrace and extinguish has always been their motto.
Microsoft has supported Linux on Azure for years now. Why would they treat FreeBSD worse than Linux?
The only "evil" that I've experience with Linux is that Microsoft has price parity between Windows & SUSE Linux on Azure, which is competitive for Windows but a premium price for SUSE Linux (and an extra premium price for RedHat Enterprise).
Linux without a support contract should always be cheaper than Windows because that's the reality with the license costs. Microsoft's competitors are far cheaper for Linux VMs, but if you're willing to pay the premium it runs fine on Azure, and performs better than Windows on the same hardware (although the gap is smaller if you run Windows headless, using Windows Core).
I mean, for SUSE or RHEL you can just build your own image and BYOL. There's no need to use the standard images. Anyway, if your infrastructure is static enough that the per hour licensing costs don't make sense then why are you even using Azure/AWS/whatever instead of running inside your own DC?
Every time our IT Director talks about Azure I want to cringe, our infrastructure is relatively static and only grows - so it's straight up MORE expensive to put anything there (and this factors in power and cooling to the datacenter).
MS has every incentive to ensure that their Operating systems get the best hardware and show they are the more stable and scalable.
I wouldn't trust an operating system company that runs a "server farm" where they have their own OS and competitors. Why would Microsoft run their competition on their own hardware & data centers? If Azure breaks off from MS and becomes an independent company, OS agnostic, then maybe they can win my trust back.
I like Azure & would only use it for MS based OS, DB etc. I would never run, nor would I recommend any other OS running on Azure, ever. There are other "server farm" vendors that I can choose from for non MS based cloud computing.
I don't think there's a single blue badge (old colloquialism for "Microsoft employee") that believes BSD and nix are "competitors". Why wouldn't Azure run other OSes? It's not a virtualized Windows hosting service, it's a virtualized OS hosting service.
Agreed on other points made on this thread regarding pricing, though.
Because it's a commoditized market. MS knows damn well that if Linux, etc were shown to be significantly slower on Hyper-V/Azure than on other platforms, they wouldn't get subscribers. Bang for the buck is an important factor in business decisions, and there are a ton of other providers out there to keep MS honest.
> and the ultimate goal of a company is to make money
It's not always like that, and it certainly doesn't have to be. Making more money than the company consumes is, of course, a good idea, but money is only a tool.
Yeah if you forget on purpose they act as patent trolls at the same time with Android, and try to make every file format incompatible with the previous versions just to ensure you keep being locked in in their products. And keeping a monopoly on PCs by having Windows installed by default everywhere. Oh, and the forced windows 10 upgrade. Is that all good for you?
You don't want to know how much money they are losing with it, all because they want a shift to a newer OS. Which makes their platform more future proof..
Yes, it's forced, no doubt. But if i were Windows, i'd rather have a lot of people a free upgrade ( and unknowing users forcing to upgrade), then leaving everyone in the Windows Vista erra :)
They are not losing any money, because Windows 10 is undoubtedly adware. It's "free" because you are the product, and they don't even try to hide this fact:
Assuming you genuinely think these are not issues, there is a little too much material for discussion. I would suggest a google (or bing...) search for
That pales in comparison to their hostility towards Open Source. They are maneuvering desperately to remain relevant among developers, but at the same time they're happy to appear on behalf of Oracle to claim that APIs are copyrightable. It would be in the best interests of the developer community to ignore them until they mend their ways.
>They are maneuvering desperately to remain relevant among developers, but at the same time they're happy to appear on behalf of Oracle to claim that APIs are copyrightable...
They are moving in the the right direction, but sometimes it seems one step forward and then two steps back. They were a gold sponsor of OpenBSD in 2015 but no sponsorship in 2016 yet http://www.openbsdfoundation.org/contributors.html.
Also on their own OS a recent experience of installing SQL Server Express shows are still very capable of inflicting pain and #clicknext arthritis.
No. They do it for the same reason Google usually open sources stuff - to their own benefit. This is to give Azure a boost in customers and image, not because Microsoft "wants to help FreeBSD" or whatever. That only happens indirectly.
>That's also another monopolistic practice: 1. Not leader on a market 2. Make yourself compatible with the leader
Is this not, like, what half of the companies in the world do? If you were launching a new browser, would you not look to make it addon compatible with popular platforms?
Of course Microsoft is playing catch-up! And where they are in the lead, they sorta leave it (look at C#). But I'm wondering what exactly you expect from any company, in general.
I'll agree that Azure is a mess. A complete disappointment, especially since Dave Cutler's name was on it. Probably has some cool core tech, but what a pain to deal with, and expensive, too! Azure is more aimed at getting traditional companies paying MS monthly direct, vs their long chain of licensing for onprem. They'll make a lot of money. But against GCE? No contest.
In short, yes. The portals are a wreck. Every time I, or anyone I know, uses it, they are pissed off. It's just needlessly "Metro" and confusing.
It's terribly slow, too. Machines take forever to startup. Their SSD story is a joke (requires special machine types on pre-sized arrays, instead of just a switch). It's far more expensive (2x to 10x GCE last I checked, depending on machine size). The networking is bizarre - all machines in a "service" share an IP. So their recommendation is to put SSH on different ports like 221, 222, 223, to get to a specific machine. Just silly.
I really, really wanted to like Azure; it'd be good for AWS to have real competition. And I am very biased against Google. But GCE is just so superior.
I suppose to see for yourself, try setting up a 3 node SSD Elasticsearch cluster on Azure and GCE. With GCE my experience is that it'll take significantly less time, even if you already know Azure and GCE.
They are reimplementing the Linux kernel in the Windows Subsystem for Linux (WSL). It's easy for them, since they have access to the Linux kernel source code.
The wine project or ReactOS reimplement NT and some of the WinAPI. However, they get no support at all from Microsoft.
They could support those. That would be a gesture of good faith, in my opinion.
Completely agree, AMD, Nvidia support opensource, like by publishing their hardware spec for free, contributing to Linux kernel. Google does it somehow with GSoC and releasing tons of libraries. But really Microsoft? Did they do anything meaning? Did I miss anything? All they do is good PR and suits behind our backs.
Microsoft research have contributed significantly to advancing the state of computing going back to the early 90's. So sounds like you have missed a lot.
The HN crowd is changing. They don't want to hear about the importance of FOSS. I just got downvoted into oblivion for talking about eee, with the same old tired logical fallacies being thrown around (but what about apple!, but at least it's open source! but that was the 90s! microsoft is different now!)
Microsoft is distributing a VM image of FreeBSD through their marketplace in binary format, that has been modified to be used on their cloud service. The license they choose to distribute it under is completely harmless, and you're still sure to find the FreeBSD licence details inside the OS itself once it's running.
There's no copyright issue here. Look at how literally any other VM image is distributed, on Amazon, GCS, Digital Ocean...
I was put in charge in comparing RemoteApp to our Citrix cluster, feature compatibility, and cost. Now, I'm part of a university so that's "negotiated". We're also part of I2, so data ingress/egress should be free as per our site contract. (Yeah, it amounted to $5, but we were billed for it against our current enterprise agreement).
I worked with a MS Engineer to set everything up. I set cost limits to kill service if we go over $200 (past the free trial).... Well guess what? They only give emails, not kill service. Your account will still accrue no matter what. The engineer said that it could kill service. So, I had limits set to 'alert me'.
Until 2 months ago. They switched what was the Beta Portal to the main portal. Doing this eliminated even my alerts I had. The account accrued around $2800, with NO emails, No alerts, and NO questionable billing calls regarding 'non-normal computing practices'.
I'm finishing up a paper and a post-mortem regarding this incident. Obviously my university can absorb this, but the points stand:
1. There is no adequate way of controlling your bill
2. Billing calculations are done with many hours of lag-time. You don't know the zinger you just got until later.
3. There is NO fraud policy... Unless you count "Too Fucking Bad" as the policy.