FreeBSD 10.3 officially supported on Microsoft Azure
azure.microsoft.com
azure.microsoft.com
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.
I then called again, promised that it would be taken care of. It was ignored after the 3rd email.
I called again, and was given someone so daft that, even when requesting a manager, he refused. That incident went nowhere.
I'm now on the 4th ticket. I might be getting somewhere... But again, they refuse to return calls and emails.
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.
Your startup qualifies if it is less than:
5 years old ~ almost 200 years old
is privately held ~ public institution
and earns less than $1M annually. ~ Billions of dollars, no clue.
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.
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.
Tue Sep 7 12:02:11 1993 UTC (22 years, 9 months ago)
Added DOS partition support and maybe badblock remappping.
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.
Either you produce a careful, generalized solution, or it's rejected.
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.
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.
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).
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)
https://svnweb.freebsd.org/ports/head/devel/hadoop2/files/
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.
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.
Has Arch dropped in popularity since then, or do you mean "in Arch's coffin [for me]" ?
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 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.
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.
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.
* http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/sy...
* http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/sy...
/opt/jetbrains/youtrack/internal/java/linux-x64/jre/bin/java -Dlauncher.app.home=/opt/jetbrains/youtrack/ -Djl.service=YouTrack -Djl.home=/opt/jetbrains/youtrack -ea -XX:+HeapDumpOnOutOfmoryError -XX:HeapDumpPath=logs -XX:ErrorFile=logs/hs_err_pid%p.log -Dfile.encoding=UTF-8 -XX:MaxMetaspaceSize=250m -Xmx1024m -Dorg.eclipse.jetty.server.Request.maxFormContentSize=5000000 -Dorg.eclipse.jetty.server.Request.maxFormKeys=10000 -Djetbrains.jetpass.admin.name=default_admin_name -jar launcher/lib/app-wrapper/app-wrapper.jar AppStarter com.jetbrains.bundle.bootstrap.Bundle
Contrast:
* https://plone.lucidsolutions.co.nz/software-development/issu...
And the redirection to $LOG and Poor Man's Daemon Supervisor in some people's youtrack.sh:
* https://www.howtoforge.com/running-youtrack-issue-and-projec...
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).
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.
When somebody wants to use zsh instead of bash, it's not described as "bash hate".
Or when somebody wants to use Clang/LLVM instead of GCC, it's not described as "GCC hate".
Or when somebody wants to use PostgreSQL instead of MySQL, it's not described as "MySQL hate".
Yet when somebody wants to use some other init system instead of systemd, it is described as "systemd hate".
Why are so many systemd supporters fixated on this vague concept of "hate"?
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.
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.
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?
You're better off looking at the rc system[1]. It leaves a lot to be desired, but it's much better than the sysV approach.
There are ongoing efforts to modernise things a bit. The 4Q 2015 report[2] mentions a few.
I like the look of nosh, personally.
1: https://www.freebsd.org/doc/en/articles/rc-scripting/index.h... 2: https://lists.freebsd.org/pipermail/freebsd-announce/2016-Fe...
0: https://www.freebsd.org/news/status/report-2015-07-2015-09.h...
> (goes and downloads FreeBSD...)
Do you always switch operating systems based on lies you see in hacker news comments?
What part is a lie? they did break userspace and they expected other projects to bend to their whim.
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.
* http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/in...
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).
Disclaimer: I'm not a fan of systemd, but serious death threats aren't the fix.
If you don't like the word "force", we can use "coerce" instead.
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.
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.
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.
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.
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.
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.
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.
Some poeple looking for concepts that age well and don't need to be rewritten all the time, because this software stuff is complex. Here is snarky comment on that idea of throwing all away and rewriting it in Linux: https://www.jwz.org/doc/cadt.html for the results of that look here: https://www.jwz.org/blog/2015/04/i-told-you-so-again/
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.
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.
>You're not an sysadmin or are you?
Nope, I'm a developer.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
[1] Amongst other OSes.
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.
Agreed on other points made on this thread regarding pricing, though.
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).
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).
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.
"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.
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.
You will argue with concrete-objective facts and they will reply with generalities and feelings.
Its a pattern -> learn to recognise it.
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.
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.
:)
\2 Also this thread is not about FreeBSD preference, neither is the topic > the topic is about Microsoft supporting FreeBSD in the cloud.
I think you have below average reading comprehension. Adjacent sentences aren't necessarily conflated concepts.
> \2
Not football?
Come on now...
And don't get me wrong: I understand the struggle. I share the point of view.
But let's just not live in the past :)
Thanks
Perhaps that's because they spent the 90's and the first half of the 2000's earning a bad reputation for everything they did
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.
>(Windows Subsystem for Linux, now that)
That's also another monopolistic practice: 1. Not leader on a market 2. Make yourself compatible with the leader
Examples include linux-subsystem, addon compatibility of Chromium, Firefox in EDGE.
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.
* Haskell
* F#
* TypeScript
* Orleans
* Roslyn
* Naiad
* ChakraIs 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.
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.
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 :)
https://news.ycombinator.com/item?id=10053622 (a default install of Win10 communicates with third-party domains of well-known ad-serving/analytics/tracking companies.)
https://news.ycombinator.com/item?id=9976298
https://news.ycombinator.com/item?id=10053352
http://betanews.com/2015/10/15/microsoft-now-uses-windows-10...
http://www.extremetech.com/computing/204595-lock-screen-ads-...
They are actively competing with Android. How is that patent trolling?
> try to make every file format incompatible with the previous versions just to ensure you keep being locked in in their products
huh?
> keeping a monopoly on PCs by having Windows installed by default everywhere
You're right, Microsoft should compaign to have more macbooks sold and force OEMs to install linux by default on 1/3 of machines.
In fact, they should just limit the number of copies of windows they sell. THat should destroy the monopoly.
> forced windows 10 upgrade
What's that? I have never heard of such a thing. I'd imagine something like that would cause endless whining from HN.
1. patent microsoft android
2. microsoft formats compatibility linux
3. microsoft force installation computer makers
4. forced windows 10 upgrade
I feel like this is much less true than it used to be. For example, in Office, OOXML has been consistent, and support for ODF keeps getting better.
...while reimplementing Apple's proprietary iOS frameworks (https://github.com/Microsoft/WinObjC).
Legal Terms
© 2016 Microsoft. All rights reserved.
"THIS SOFTWARE IS PROVIDED BY MICROSOFT 'AS IS'..."
There's no copyright issue here. Look at how literally any other VM image is distributed, on Amazon, GCS, Digital Ocean...