I am developer, but mostly work on desktop apps, or embedded devices or lataly on some MVC applications. But reading things like
"A Container-Native Stack for Modern Applications and Operations
Increase development velocity while simplifying operations."
I have no idea what should I imagine and what is it good for...
any good introduction or explanation into what is it they actually do?
In the ancient past, like when I'm from, you'd write up a few different bash scripts to help you provision each server type. But setting this all up, you'd still have to run around and create 20 servers and provision them into one of 5 different types, etc.
Then there's chef/puppet, which takes your bash script and makes it a little more maintainable. But there are still issues: huge divide between dev/prod environments, and adding 5 new nodes ASAP is still tedious.
Now you have cloud and container orchestration. Containers are like the git repos of the server world. You build a container to run each of your apps (nginx, redis, etc), configure each once (like coding and committing), and then they work identically on dev and prod after you launch them (you can clone/pull onto hardware). And what's more, since a container image is pre-built, it launches on metal in a matter of seconds, not minutes. All the apt-get install crap was done at image build time, not container launch time.
Things are a lot easier now, but you still have a problem. You're scaling to 30, maybe 50 different servers running 6 or 7 different services. More and more you want to treat your hardware as a generic compute cloud, but you can't escape that, even with docker, your servers have identities and personalities. You still need to sit and think about which of your 50 servers to launch a container on, and make sure it's under the correct load balancer, etc.
That's where Kubernetes steps in; it's a level of abstraction higher than docker, and works at the cluster level. You define services around your docker containers, and let Kubernetes initialize the hardware, and abstract it away into a giant compute cloud, and then all you have to do is tell kubernetes to scale a certain service up and down, and it automatically figures out which servers to take the action on and modifies your load balancer for that service accordingly.
At the scale of "a few servers", Kubernetes doesn't help much. At the scale of dozens or hundreds, it definitely does. "Orchestration" isn't just a buzzword, it's the correct term here; all those containers and services and pieces of hardware DO need to be wrangled. In the past it was a full time sysadmin job, now it's just a Kubernetes or Fleet config file.
Disclosure: I'm currently writing a book on Docker. Disclaimer: I have not had my coffee yet.
Edit: Since someone asked, I'm writing a book called "Complete Docker" which will be published by Apress. I don't know the exact pub date that Apress will launch it on, but I expect it'll be available in October.
Now I wonder.. how many projects actually needs these kind of solution when even StackOverflow can do without it (they are in the range of few servers)? I would imagine it would be only few top popular web apps/services, but by popularity of these posts it looks like it is probably a lot more...
Does it make things better, though? Yes. Yes it does.
Kubernetes was designed at Google where they reaaaaally feel their scale problems day to day.
I see Docker/Kube/CoreOS/ etc as the natural evolution of where we were already going. Bash -> puppet -> vagrant -> docker -> kubernetes. Less abstract to more abstract.
So it's actually "only" an incremental evolution in terms of managing the server ecosystem. But it's a revolutionary improvement in how we think about server ecosystems, which is why many people struggle with Docker et al at first; it's a brand new mental model.
Sometimes you need to have the ability to run more services when your "web-scale", but even if you're not at that point, scaling how you deploy new versions, and new services is still important.
Tools like docker, and Kubernetes really help with the application delivery aspect, and really enable you to rapidly iterate on your project.
You might have a site with 100-1000 users, not huge by any means, and 1 server could probably handle all of your needs. But once you start adding other components, perhaps redis, or a runtime like nodejs, those can all be managed, but if you need to rapidly iterate, something like Kubernetes/docker can make updating or deploying these easier in the long run.
Really, why should cost anything to have basic, low-traffic, site on the internet today? That's the quetion I ask myself.
There's also other aspects, like being able to spin up the newest PostgreSQL within minutes, and when you're done you rm the container and image and have no trace and/or side effects.
There's some pretty useful multi-container configurations out there too, like a dockerized gitlab environment: https://github.com/sameersbn/docker-gitlab
stackoverflow is just a nice example that you don't need dozens of servers, even when you reach their scale.
I do believe Brook's The Mythical Man-Month does also applies to computers. In that communication overhead soon outweighs the benefits of adding more computer nodes.
Something I never understood with containers: where do they store persistent data, e.g. MySQL's /var/lib/mysql - and how does upgrading work, i.e. when the apt-get postinstall script runs transformation on the persistent data, how is the transformation applied to the "clones"?
You don't upgrade a running container. Imagine that containers are immutable; to launch a new, upgraded version, you re-build the image in your build/dev environment, and re-launch the image into production. If you're using a volume, you get to use the same backing data.
It's rare that apt-get postinstall will affect any data that you would persist -- app-specific data you'd keep in the image/container, and mysql data for instance you don't really want apt touching anyway. But if a data migration is necessary you'd either manage it with a "utility container" (image that's designed to run a script then stop, rather than run and keep running).
Load balancing two separate servers you can consider as active-active for the terminology.
Right now the first several chapters serve as a "I'm a programmer but know nothing about Docker" guide, the mid of the book dives into Docker-specifics (how exactly volumes work, how Docker networking works, etc), and then it graduates into the Docker Ecosystem, dedicating some time to covering tools like Kubernetes, CoreOS, Fleet, Amazon ECS.
The latter portion of the book is a number of recipes: how to get a Ghost blog running behind an nginx proxy; how to launch WordPress with MariaDB; how to launch an ELK stack, etc.
And hopefully your book will mention SmartOS and Triton and zones providing full isolation for Docker.
"At the scale of "a few servers", Kubernetes doesn't help much. At the scale of dozens or hundreds, it definitely does."
So now I know I don't need to learn much about Kubernetes unless I have "dozens or hundreds" of servers to manage.
One thing Kubernetes IS helpful with at small scales: portability. If you're fully Kubernetes/Docker, then you won't get locked into (eg) AWS's ecosystem. It's relatively easy to pick up an entire Kubernetes cluster and move it from AWS to DigitalOcean to private hardware.
So even if you're at small scale today but want to design for portability, I'd definitely look into Kubernetes.
Now, think about it from a reductionistic engineering perspective. What do I really want this server to do? Well, it accepts TCP connections, parses a request to figure out which file (at the time, it was all files) to server, sticks an HTTP header on the file, and shoves it down the socket.
This task is so simple that a skilled network programmer can nowadays literally bash together a 1990s-level static HTTP server in an day, with nothing but a socket library and some basic string handling. (It may not be great and it probably is insecure, but, well... see also "1990s web server"....) The code to do this is perhaps in the dozens or hundreds of kilobytes.
But that's not what I had. I have a full computer that physically needs to live somewhere. It has hardware ethernet and hardware graphics cards and a physical monitor and a power supply and RAM and, basically, hardware hardware hardware, the failure of any one of which means the system is either difficult to change or outright down. I have an entire Windows operating system, which even in the 1990s was hundreds of megabytes of code, endless code. Code for a windowing system, for pete's sake. Code for the audio subsystem. Code for accessing the hard drive. Code for access code that accesses code. Code code code code code, a bug in any one of which means the system may be down or insecure. My website, which at the time was quite likely in single-digit megabytes in size, was a tiny directory lost in a sea of files on the hard drive.
Over the past 20 years, the commodity hardware world  has been slicing away at the fact that several dozen kilobytes of code are being accompanied by hundreds of megabytes of support and literal pounds of physical hardware. Hardware went first with VMs. VMs got lighter and lighter. Lightweight hypervisor solutions sliced away at the heaviness of the VM. Containers slice away at the OS. Things like Kubernates slice away at the idea of a container living somewhere physically.
We're trying to free that several dozen kilobytes of code to be just several dozen kilobytes of code, as flexible and easy-to-deploy as several dozen kilobytes should be, if you weren't mired in the world of hardware and OSes and code and strong physical connections.
(Data storage is more complicated, but in a lot of ways, the same principles are in play.)
Operationally, containers are very exciting. However, in terms of "magic technologies I don't understand", I don't think they're worth stressing about "getting old" or anything. It's mostly "just" a big pile of practical considerations in trying to not just build that world, but in some sense also undo decades of grinding-in of the physical world to our operational considerations. If you want worry about getting old and out-of-date, worry about that let you do something that you couldn't before, like GPU programming or deep learning.
: Which must be specified because mainframes beat us all here decades ago, in a lot of ways.
Cloud orchestration: the logic for how your platform provisions and launches instances (think ec2) into your fleet of resources.
Container orchestration: the logic for how your applications (containers) are distributed across your fleet of instances
Kubernetes: Software that runs on your fleet and manages how/where/when container orchestration happens. There are many players in this space such as mesosphere, swarm, ecs and so on.
1. Anything that is in the world when you’re born is normal and ordinary and is just a natural part of the way the world works.
2. Anything that's invented between when you’re fifteen and thirty-five is new and exciting and revolutionary and you can probably get a career in it.
3. Anything invented after you're thirty-five is against the natural order of things.
- Douglas Adams
i'd argue that this situation is if you're a developer at a large company or enterprise. developing can be a nightmare because testing and/or deploying is so difficult. sometimes this is by design, sometimes by virtue of incompetence. other times people want to change it, they just don't know how.
tools like this claim they can change this. whether that's true or not. well, that depends on more than just what tools you use but it is part of the equation.
Please, please continue to develop your public cloud offerings. Having options other that the myopic, me-too, feature-matching, monoculture that is AWS/GCE/Azure is incredibly important.
That said, for my use profile, you guys need to work on your price competitiveness. Hopefully Samsung will inject the necessary cash for economies-of-scale.
I'm sure they will. They are a top contributor to open source:
Source: I applied for the job. I didn't get it ;-)
It's starting to feel like I need to consult a lawyer before I could ever publish an open source project, and that's never going to happen. I'd rather just stop publishing.
That is a good, honest question, but there is a different standard of expectations for some random programmer doing a project and one of the biggest, most powerful multinational corporations on the planet with business operations (and legal advisors) in most of the world's countries.
If Samsung has the legal muscle to go up against Apple and others in the courtrooms of the world, and the technical muscle to customize multiple operating systems for countless products, they have the resources to read and understand the Linux license. While inept bungling is always a possible explanation for any party, a more likely explanation for a license violation for something as fundamental as an operating system by any party with that level of resources (if one were to ever occur) would be that they examined the issue, understood the situation, and decided that they could probably get away with it.
So, if you "know must mainstream licenses", you should be aware of this.
The amendment is actually the first paragraph of the COPYING file. If you modify any of the terms of the license directy, you have to remove the preamble and refer to it as something other than the GPL.
The other option for modifying the GPL is to distribute a separate LICENSE file alongside it stating something like "this software is released under the GPL, except for <specific changes>". When this happens, there's almost always an FAQ somewhere on the internet describing what the changes are intended to mean.
So, basically - check the source files to see if they mention a license, then check if there's a file named LICENSE, then check if there's a file named COPYING. One of these should always point you to the right license.
Additionally, as a point, it's not actually a modification of the license, merely a clarification - see section 9 of the GPLv2, which states that the program must explicitly state that it is usable under later versions of the GPL to be usable under later versions of the GPL. The boilerplate text that GNU give you to put at the top of each source code file does that by default, but, it's not required.
* ... apparently Linux has a modified version of the GPLv2? I would never notice that,*
From the point of view of a personal project it doesn't matter that much. If you accidentally breach a license and someone notices they'll tell you and you'll fix the issue.
It gets much hairier once money is involved (i.e. OS code used by a company like Samsung) but the process they need to go through is no different from the due diligence that they have to do when licensing non-OS code from other bodies (commercial or otherwise).
When transitioning from pet project to commercial interest things are a bit more muddy. In the case of an individual or small company making the transition there may be some pain as they are not initially setup for this, but in the case of a commercial interest taking over (buying the project, taking over the smaller company, employing the individual specifically to work on the project, just negotiating non-OS use of the code etc.) this is again covered by the same due diligence requirements they follow when dealing with commercial code.
> I'd rather just stop publishing.
This only affects making modifications to other projects or taking some of their code to supplement your's (in both cases you are creating a derivative work), and even then only if you subsequently publish the work (i.e. it isn't purely a personal or in-house project). It shouldn't stop you publishing work that is definitely your own, just chose a license that you do understand.
If in doubt, write it yourself. For bringing in libraries (as "write it yourself" is seldom completely practical for all but the smallest projects) keep to the "soft" licenses that you understand (in no particular order this for me is: BSD, MIT, CC, LGPL, ASL) and avoid the "hard" OS licenses (GPL proper) & non-OS licenses unless you intend to stay GPL or accept the limitations of commercial/other licensing, and ignore code under other licenses unless you have time to read and understand them. Also avoid code with no clear license.
I can't say I know either way, however I do recall their Tizen SDK licensing not being accepted as open source due to it only granting the right to use certain components on 'Tizen Certified Platforms'.
Which means the larger companies* are probably on schedule for development to start slowing because of technical debt. And therefore solving that (modern development practices and open source involvement!) will become a competive advantage.
* Sadly, the smaller companies will probably always be hacked-together-MVP stacks on top of whatever release they started dev on
"In February 2014, Joyent announced a partnership with Canonical to offer virtual Ubuntu machines."
Wiki: "In journalism, lede is an alternative spelling for lead paragraph."
We use Joyent for nodejs microservices, chiefly any server side DOM manipulations (using jsdom), and it's been solid! Currently evaluating docker container management and will give Triton a go...
Just saying, there's a bit of bias that's probably worth recognizing.
I don't remember the exact Korean wording, but a common phrase said by Samsung engineers (under their breath) in Korea basically translates to "I'll do what you say, but it's only because I'm at <name of a Japanese labor camp that I forget now>." My time there really made me appreciate how much better we have it here!
Can you explain the cultural aspects (and management shortcomings) in more detail for those of us who haven't experienced Korea? Thanks.
In general, the culture is very hierarchical (respecting elders) thus seniority and age play a big factor in leadership. I would assume that this makes it very easy for mediocre (but good enough to survive) management to stay in positions far too long. Asian culture, but Koreans especially, can be masochistic1 and martyr2 like in their methods. In some ways this creates a tremendous amount of excellence, but it also creates soldiers who may not necessarily be incentivized to innovate, and those who innovate, out of cultural respect will tend to not dare "disrespect" seniority. Being a good soldier makes for career advancements.
Management can also claim the failures of the company as their own personal failures, rather than the gray collective failure of a group(e.g. japanese ceo's claiming company failure as their own), thus employees kind of get absolved of blame.
Work in Korea also tends to be a live at the office kind of affair. It's not uncommon for the white collar folk to go into work at 7a, and stay until 7-9p. Then go drinking with coworkers until midnight, and rinse and repeat. While this makes for very strong bonds amongst coworking peers and better teams, I would imagine that it also takes a toll on the mental capacity of the workforces.
Mainly, I wouldn't be surprised if work in Korea tends to be death marches all the time based on the martyrdome syndrome and masochistic syndrome for career advancement.
1 - http://askakorean.blogspot.com/2010/01/koreans-english-acqui... makes 30k vocab flash cards to learn english
2 - https://www.youtube.com/watch?v=S-yD4OfY8cM boyfriend gives up both eyes for girlfriend he blinded. Why not keep 1 eye?
Basic courtesy and being polite are pretty much universal, so try to be humble and keep an open mind and observe. Older people often are more experienced and savvy about how to handle something so being deferential to them is a no-brainer. You'll spot the incompetent ones soon enough and so continue being polite but ignoring their guidance.
One thing that drove me nuts but took a little while to figure out was that people would almost never say no to a request. I would ask if something was possible and they would pretty much always say yes, not wanting to disappoint, but I would have been better off hearing a 'no, sorry'. I wanted a realistic answer and theirs were often far too optimistic.
Me: "Mr Son, can we make it to Osan in 30 minutes?"
Him: "Yes" (always yes)
An hour later we show up late to another hospital with a very impatient air crew idling and waiting for our patient transfer. We would have all been better off hearing a "No, it takes an hour". Just one small example but this scenario repeated frequently.
I learned that when speaking to a group or doing a presentation it was customary to apologize for your inexperience on the subject and promise to do your best. Tim Berners-Lee could start a talk with "I'm sorry I don't know much about the World Wide Web..." for example and Westerners would laugh but the locals would be like "He's off to a good start".
Understanding this helped me get more realistic answers though. Even if I thought I knew an answer I would keep the question more open-ended to solicit a better response.
Me: "Mr Son, I'm sorry but I forget how long it takes to get to Osan, can you remember?" (said even after making the trip solo dozens of times in often difficult and stressful conditions).
Him: "Ah yes, there is new road construction halfway there so I'll teach you an alternate route to bypass it. We'll be there in about 40 minutes".
Had I not learned to ask a better question, I never would have learned his faster alternate route.
Korea was a lot of fun and I really enjoyed hanging out with the older Koreans who worked on our base, they were a constant source of good info once learned how to talk to them. I also had a 'ration card' entitling me to buy the occasional bottle of Crown Royal on base and give them, which always helped!
Whenever someone in HQ tells you to do something, you do it, and if not, you get punished, whether that's through decreased compensation or they fire you. You can be the engineer that tells managers that you can't draw parallel lines that intersect (metaphorically speaking), but they don't want to hear it unless the competitor proves them wrong with sales results - they are notorious for not innovating, but copying competitors. Samsung runs on waterfall from top to bottom. Oh, and if they tell you to do something early in the morning, you jump.
Samsung also tends to mainly promote Koreans - if you're not Korean and want to get ahead, you'd best look elsewhere because you're not likely to accomplish it. I hear this also applies to their American divisions as well, but I do not know anyone who has worked for them here. The family who owns the company has had some history with corruption in Korea as well, so this isn't too surprising.
More on the cultural side, Koreans can be very rude by western standards - it also is demanding on expectations. You're often expected to dress a certain way (this part is no different from most of the world, but disregarding norms is probably more harshly regarded in Korean culture than most), as well as join bosses & other co-workers going out to drink and doing karaoke at night. Deferring to father-like/older figures is built into the language with even how one addresses another, and that bleeds into how companies operate (& people treat each other - even being one month older can come into play unless you have leverage of some sorts). There are also built in opinions on processes, from parenting to schooling to work. Koreans tend to also be quite xenophobic/racist, even against Koreans who cannot speak Korean (maybe even moreso towards Koreans who cannot speak the language). Society sort of disowns those who are not immersed in the culture. Non-Asian foreigners are special, but they are excluded from much of anything of consequence (probably to avoid stirring the pot with other nations).
There's probably a lot more I'm missing here, but tl;dr if you aren't an extremely mentally tough person, working for a Korean company in Korea can crush you thoroughly. It is a different world, and people who do so from western society are left without a support base.
That said, I think it's fair to say that among many Koreans Samsung is viewed with respect but no affection. The company history dates back to the Japanese colonial period and is imbued with the pre-WWII Japanese zaibatsu mentality. What some posters are generalizing as "Korean" seems more the rather specialized local culture of Samsung. Personally, I would never work for them.
There's also lots of very positive things about Korean culture, just like there are about Western cultures.
This quote from the parent comment:
"Samsung managers are often corrupt and treat their employees like trash"
makes me feel like I'm not fully aware what really goes on and is not something I like to actively support.
That's Samsung proper. Not their incubator setup, which is different. Companies like Mapzen were bought by Samsung, but have a completely different culture.
This is good news for node.js since what this means is more money gets poured into node.js development.
For example Microsoft pouring money into JS seems to have lead directly to Typescript.
Later, I visited their HQ in Korea and met some of their Indian and Korean development teams. They were competent but the work culture was toxic. People were expected to attend 11PM daily review meetings where the issues list was painfully re-read pointlessly and nothing at all was achieved. Koreans were expected to live in numbered company compounds, catch a numbered company bus and ascend to a numbered floor in a numbered company skyscraper after an airport security style physical check. Smoking allowed strictly twice per day in a designated corner of the compound. All movement is tracked. Psychotic Confucian management style. I honestly thought to myself: if this is a vision of the future, I want no part of it.
Samsung Semiconductor is happy to supply chips to Apple even though they're the biggest rival of Samsung Telecommunications the builds the Galaxy phones. Conversely Samsung Telecommunications may or may not pick Samsung chips for their Galaxy phones, it doesn't really matter.
So I guess it depends to what division they will be attached. If they're attached directly to the group, they may actually keep complete freedom and just have a different owner.
This could just be clashes between US and Korean management culture, or perhaps just some instability in a new research lab.
Compared to the kind of stuff that Microsoft, Apple have done in the past in the software world.
And I do not see how this is bad, maybe Samsung is trying to learn why 'Western' engineering is so much superior to 'Asian' engineering by this acquisition ?
I guess they are making efforts to work on this:
> And I do not see how this is bad, maybe Samsung is trying to learn why 'Western' engineering is so much superior to 'Asian' engineering by this acquisition ?
It depends if you want to be part of their learning experience or not! Chinese companies have adapted pretty well to acquisitions and satellites, so it isn't an Asian thing. Japanese companies have been known to have similar problems in the past and even currently (though it really depends on the company, and many have had a lot of time to gain experience).
Actually, Japan is another country that is notorious for not being as great as they should be at software, maybe there is a common thing going on?
Microsoft is a software company. Samsung is not. If you think they are, then you probably haven't used one of their bloated, buggy phones that they stop updating way too soon.
There's a reason Samsung seems to be not that great as a software shop. I wrote up a long post on HN almost 2 years ago (God, it's been 2 years!!). I'm reposting the link here.
We were offered either one or three free years of hosting on a Joyent SmartMachine, depending on what your initial investment was. After this free trial, you would be converted to a regular customer.
Adding my voice to the bitter-parade. Joyent wouldn't be where they are today without us early bootstrap investors. It was basically a Kickstarter campaign before Kickstarter existed. Not only do I feel like I failed to receive my early investor benefits, but WORSE off was how the whole situation was handled. We had to beg and plead to get our data back. The company essentially went dark to all of their oldest, most loyal customers.
I totally take the "lifetime" deal with a grain of salt but it wasn't like the company folded because it ran out of money or wasn't successful. It was more like we got successful so we forgot about the little people.
Congrats to all my former colleagues who are absolutely amazing at their jobs and wonderful people to work with. Samsung looks like a very good match. Hope the transition goes well.
So that's how I saw it progressing. Samsung was looking into how to get in on the Internet of Things, stumbled across Manta, and it went from there.
If you want to store objects in a distributed way, why not just use something like RethinkDB, which has proxying/sharding etc. built in? RethinkDB even has a way to execute code with 'js'.
Or for serverless processing, why not AWS lambda or the crop of clones?
Say what? SmartOS is based on illumos, the only free, open source SVR4 UNIX out there.
Get the code: https://github.com/joyent/illumos-joyent
Build it! https://wiki.smartos.org/display/DOC/Building+SmartOS+on+Sma...
Modify it: https://wiki.smartos.org/display/DOC/SmartOS+Developers+Guid...
I'm not sure where this will take things with Samsung, likely backend services to support their own "store" on their devices separate from Android. If it's internalized, I only hope they release more of their infrastracture tooling, which is very cool to say the least.
- lx-branded zones and window's new layer are both doing system call translation---you're post doesn't contradict this but doesn't make it clear either.
- At some point lx-branded zones where equally untested.
- "Desktop class" is misleading because NT was designed for servers. Now yes Windows as a whole is hamstrung by a business model putting desktops and backwards-comparability first, but by definition the Linux layer can ignore a lot of Win32 precedent.
- Yes Illumos is Unix and NT isn't, but the difficulty in translating linux systems calls lies not with the ones backing posix-interfaces, but the Linux-specific ones. (Joyent devs can give you some great horror stories here.) It may be a bit harder with NT but it was hard already.
I'm ignorant on why Joyent is so superior to Azure. Can you give some reasons? As an outsider, Joyent looks like a small company with unproven (large, successful customers are the main criteria) products that cost more than the comparable solution from AWS, GC, Azure.
It's a good product fit, but the fit is so good that Microsoft basically built a more-complete competitor in the form of Azure. They built Joyent instead of buying it.
LinkedIn was different because Microsoft could never build LinkedIn itself.
edit: I should have been more specific.. when an open source project is under a company's wing and it gets acquired, you don't know what can happen, even under MIT. Look at express recently. Since it's the under the Node Foundation now, this is not a big deal. Had it happened a short time ago, there may have been further turmoil in the community.
So actually all of Cantrill's worries with Oracle exist with Node.js's license. I am sad when I see large free software projects licensed under MIT, we are doing ourselves a disservice by allowing proprietary software to take advantage of the free software we've developed.
 It's part of his Fork Yeah! talk about the fork that is illumos.
On the other hand, I have nothing against CDDL. I think the incompatibility of CDDL with the GPL is what saved the illumos community (even if inadvertently) from having their technology cannibalized by GNU and Linux. I'm happy that BSD is benefitting from illumos (and vice versa), but I'm even more happy that Linux isn't. <--- I do not represent anyone but myself, the position expressed here is my own and not of anyone else.
Not proprietary software? Not "open source" licenses that don't allow modification (which is also proprietary)? The GPL? The thing that gave us free software in the modern world? Well, that's certainly one opinon.
> On the other hand, I have nothing against CDDL.
The CDDL has a provision that if any part is held unenforcible it will be modified to make it enforceable. As a matter of licensing, that's incredibly devious and bad. There's other super dodgy parts of the CDDL that make it a bad license purely from a license point of view, let alone from "freedoms given to users" perspective.
> I think the incompatibility of CDDL with the GPL is what saved the illumos community (even if inadvertently) from having their technology cannibalized by GNU and Linux.
What are you talking about? Why do you care if GNU/Linux takes your code and modifies it? No damage is done to the original.
> I'm happy that BSD is benefitting from illumos (and vice versa)
Actually, because CDDL is somewhat-but-not-really copyleft, many BSDs essentially have copyleft requirements if you enable ZFS or DTrace. Which is funny, given how much they go on about "freedom to make proprietary software" (something I'm against).
> I do not represent anyone but myself, the position expressed here is my own and not of anyone else.
Your position is also wrong.
This is more about the fact that when they take it it's worse for the project than a proprietary fork. When BSD/MIT/(other permissively licensed code) is used, modified, and re-licensed to GPL, the permissive project can't take those improvements without also re-licensing. The CDDL indeed saved illumos from being cannibalized and disappearing as a community. Had its features been easily ported to Linux without a licencing problem, the project would probably not have survived, simply due to the fact that there would have been few reasons to stick with it. It's not just about what code is out there, and you should know that.
>Actually, because CDDL is somewhat-but-not-really copyleft, many BSDs essentially have copyleft requirements if you enable ZFS or DTrace. Which is funny, given how much they go on about "freedom to make proprietary software" (something I'm against).
Only in regard to changes to DTrace and ZFS. Still totally fine to build proprietary versions of BSDs that include those pieces.
I won't go so far as the grandparent post here, but I'm one of those developers that couldn't give half a care about "user freedom". It's nice to have source as a developer, but my motivation has never been "freedom", insofar as using and understanding the software, so I understand where he's coming from in his complaints about the GPL. As a developer, it's more constraining than the permissive licenses out there. To some, that's a good thing.
> This is more about the fact that when they take it it's worse for the project than a proprietary fork.
... Who is it worse for? First of all, that almost never happens. But for users, there's no difference (if anything it's an improvement because they now have better protection of their freedom) and the original developers can just ignore the fork or merge the code and change license (which isn't possible with a proprietary fork).
> The CDDL indeed saved illumos from being cannibalized and disappearing as a community. Had its features been easily ported to Linux without a licencing problem, the project would probably not have survived, simply due to the fact that there would have been few reasons to stick with it.
I think that's a very irrational fear. GNU/Linux took plenty of BSD code and BSD still exists, many different projects take ideas from each other -- it's what's called "collaboration".
> I won't go so far as the grandparent post here, but I'm one of those developers that couldn't give half a care about "user freedom".
It's disappointing that you don't want to actually make the world a better place (not in the standard bullshit silicon valley sense) by giving people freedom.
"Nope—the great problem we face is that people would wrap the GPL around our code, and lock us out in the same way that these supposed companies would lock us out.
Just like the Linux community, we have many companies giving us code back, all the time. But once the code is GPL'd, we cannot get it back."
— Theo de Raadt, from https://en.wikipedia.org/wiki/Theo_de_Raadt
GPL actively reduces freedom.
Are you kidding me? The Linux rabble will happily take what they want and discard the rest like a rotten carcas, with fanfare all the way how "Linux is the best!" Thanks, but no thanks. I don't want a superior operating system to be discarded for that steaming pile of excrement after the Linux "developers" swipe every good piece of technology from it.
> It's disappointing that you don't want to actually make the world a better place (not in the standard bullshit silicon valley sense) by giving people freedom.
We do (well, I do), just in a world without GNU and without GPL. That is a better world for me.
This is embarrassing.
Would you prefer Windows? Because that's where the world was heading in the 90s. History happened, and what it shows is that Linux arose at a time when EVERYONE thought that Windows was going to steal Unix's throne. It's amazing you have such negativity about a piece of software.
I would prefer sgi IRIX 6.5, but that's dead.
In the absence of IRIX, illumos and SmartOS are the next best thing, so that is my next preference.
> Because that's where the world was heading in the 90s.
> History happened, and what it shows is that Linux arose at a time when EVERYONE thought that Windows was going to steal Unix's throne.
Not everyone. I went through the entire '90's using Sun SPARC, sgi, hp PA-RISC and Commodore Amiga computers, and neither did Sun Microsystems. Didn't touch an intel-based PC until 2002, when I put together my first one, and even my current intel based PC runs Solaris 10.
Sun Microsystems was the only company which refused to bow, and continued developing Solaris. And while we know that eventually that company died, the OS lives on, and is being very actively developed, with new features added, and new technology invented.
> It's amazing you have such negativity about a piece of software.
You would also have it if your telephone rang with priority 1 incidents at two o' clock in the morning because Linux has a problem which I would not have had if I were using SmartOS. Then you'd have bonus negativity when you'd have to log into a crisis bridge and explain to a whole bunch of angry managers (who don't understand a thing about their decision to use Linux) that the application broke because Linux killed the service when it ran out of memory and oh by the way the data is also corrupted because the filesystem is a design from the '90's of the past century. And no I cannot find out why the application ran out of memory because the OS is locked up and when I reset it, I cannot get a core dump for analisys because I do not have adequate tools for that on Linux.
Computers and UNIX are my life calling, and since I am passionate about them, I spend extraordinary amounts of time working on them and researching them. Even what little free / spare time I have, I spend doing computer research and system engineering. So when according to my research and experience, something as inferior as GNU/Linux starts to push out a better solution just because of ignorance, it is only logical I have developed an intense hatred of it. It is messing with something I hold very dear, illumos and SmartOS - it's messing with UNIX.
And when I cannot find any SmartOS jobs where I live because every single ad says Linux-blah-blah Linux, you bet I hate it even more, since working on it, I get to experience first hand just how bad Linux is. When I'm forced to suffer because I am ordered to use Linux, and have problems I would not have if I had been on SmartOS, it's becomes personal, and it also becomes not just personal, but professional.
At home I have SmartOS and do not have a single issue I have at work, because I am using a different OS, a better one, and I love every microsecond developing on it and using it.
Now if you'll excuse me, I have to go back to do some more software engineering. On GNU/Linux.
BSD wouldn't have been free software without Stallman (he convinced them to release their changes under a free software license publicly). Same with OpenSolaris (the idea of free software wouldn't have existed). So, GNU was central to us not being in a world dominated by proprietary software.
But GNU was never going to be ready (Hurd will never be finished), so Linux offered us the opportunity to live in freedom. And people ended up using it. Yes, the kernel Linux has _many_ problems. But without it, we would be living in a much worse world than even the most broken of Linux interfaces and semantics. But GNU/Linux definitely was a saviour for Unix.
Yes, Sun was still holding on to Unix. But they were the only one (apart from Be, which folded soon after). But do you really thing they would've ever created OpenSolaris if GNU hadn't come into being and GNU/Linux hadn't started to dominate the market? I doubt it. History is odd like that.
Maybe you would be living in a much worse world, if your entire world up to that point in time consisted of Microsoft(R) Windows(R) and an intel based PC tin pail.
I was fine with using a binary only version of Solaris, IRIX, and HP-UX; so long as I could get those gratis, along with compilers and software RAID, that was fine by me, as I had no interest in building my own OS at that point in time (unlike now). I also grew up on Commodore computers, where, when one bought a computer, it would come with detailed schematics, and the hardware was documented in detail.
I can only offer you empathy for the world you grew up in, but that does not give you the right, nor are you correct in assuming, that everyone else lacked the same freedoms you lacked: not everybody grew up in the United States which has fascist copyright laws. The country where I grew up did not have any copyright laws, and if it weren't for that, it would still be in the dark ages of Informatics and computer science, and I would not have ever become a computer professional. Other countries, for example Sweden and Spain, still have lax copyright laws, and thank goodness for that. The point is, don't make the error of assuming that the entire world was mis-fortunate and lacked freedom in this sense.
That's not the point at all. You didn't have any software freedom -- how did you modify your software? It's great that you could distribute it in your country, but you didn't have the means to practically modify software.
Also, gratis isn't the point. I don't care if I have to pay for GNU/Linux or any other software, I just care about whether or not I get software freedom as a result.
> not everybody grew up in the United States which has fascist copyright laws
I didn't grow up in the US.
> don't make the error of assuming that the entire world was mis-fortunate and lacked freedom in this sense.
You lacked the practical freedom to modify software (okay, so you didn't have copyright but if you don't have the source then you can't pracically modify your software without spending far too much time reverse-engineering it). I hate to break it to you, but you did lack freedom.
In a program called a debugger, which back then was known as a monitor. You pressed a button, and the monitor was started from a cartridge, or you loaded a monitor, and then you loaded the machine code. And then you stepped through that disassembled code, and then you inserted a breakpoint in a strategic place. And when the program would stop execution, you'd consider the state of the program, and then you'd make the desired modifications, either by changing the existing processor instructions, or by adding your own code and hooking it in. Worked for an entire generation of crackers, I don't see what the big deal is.
So in that sense, there was no closed source, as nobody can really hide machine code, and believe you me, people have tried, and then some! But to a cracker, to a really good coder, every piece of code is open source, because there is nowhere to hide.
A much bigger deal was if you were not capable of this, because it meant you were a lamer and didn't make the cut.
Wait until you discover the BSD license, which lets you do whatever you want with the code... you might get a stroke (:-D)
GPL gave me no freedoms, it gave me the GNU userland tools and GNU/Linux (illumos / SmartOS and AT&T SVR4 tools are just fine, thank you, do not want GNU!)
GNU / GPL: DO NOT WANT!
> Your position is also wrong.
Luckily I don't have to license anything under the GPL, GPL cannot take that away from me as long as I don't link with the kernel code licensed under it, or derive code / work from it.
And I'll be extra careful I don't ever land myself in a position where I would have to license something under the GPL. Any other FOSS license is better than the GPL, I have no problem with open sourcing, and cannot wait to clean up my code in order to set it free.
But not under the GPL license.
Finally, CDDL is both FSF and OSI approved: the open source initiative looked over the CDDL license and deemed it to be in compliance with open source. I will take what is in my view their expert finding over your position, but thank you for sharing your opinion.
> Wait until you discover the BSD license, which lets you do whatever you want with the code... you might get a stroke (:-D)
Including someone taking my software, making it proprietary and mistreating users. I would prefer that less people use my code than someone doing that.
> GPL gave me no freedoms, it gave me the GNU userland tools and GNU/Linux (illumos / SmartOS and AT&T SVR4 tools are just fine, thank you, do not want GNU!)
Wow, so much vitriol for a license that actually created the world we live in today. I'm slightly impressed by how much you hate a license that gives users perpetual freedom. Also, why do you think that CDDL's weak copyleft is better than GPL? I understand, but don't agree with, people who hate copyleft altogether -- but you only hate the GPL.
> Luckily I don't have to license anything under the GPL, GPL cannot take that away from me as long as I don't link with the kernel code licensed under it, or derive code / work from it.
You can dual-license modifications to GPL code. I think doing that is dumb, but you can do it.
> And I'll be extra careful I don't ever land myself in a position where I would have to license something under the GPL. Any other FOSS license is better than the GPL, I have no problem with open sourcing, and cannot wait to clean up my code in order to set it free.
It's so sad that you don't ever want to make contributions to a large body of free software.
> Finally, CDDL is both FSF and OSI approved: the open source initiative looked over the CDDL license and deemed it to be in compliance with open source. I will take what is in my view their expert finding over your position, but thank you for sharing your opinion.
I know its a free software license. I'm just saying it's a bad free software license. The original BSD license was also a bad free software license (requiring you to add a line to all advertising about the source project).
Yes, and since that world is the world of GNU/Linux, it sucks, because compared to illumos and SmartOS, GNU/Linux is a vastly inferior product in terms of capabilities, performance, end to end data integrity, post mortem analysis, as well as storage, day to day system administration, and development capabilities.
I don't want to live in a world with those kinds of "freedoms". I don't want to live in a world where people who do not have enough experience, or do not care break my applications because they constantly mess with the core OS functionality in a way which breaks or fundamentally changes things, arbitrarily, because they can't see past their lone desktop personal computers, but they think they can, and they think they know what needs to be done. I don't want to live in a world where the core OS functionality like startup and shutdown is still in violent flux, along with everything else. If it weren't for GNU, if it weren't for GPL, we would not have the world we have right now. The situation is bad, so very, very bad.
I want to live in a world where my data is safe, where my operating system provides a solid foundation of end to end data integrity and guarantees me backwards compatibility so I can build good, reliable software, and when that software needs troubleshooting, I have all the tools I need to perform effective telemetry analysis. That world is a world without GNU/Linux, a world where SmartOS is the substrate and illumos is the kernel, and where I, and not the FSF, hold (sometimes joint) copyright to the work I did.
If I had it my way, copyright law would be completely abolished, making all of this license nonsense completely pointless, and it would be survival of the best coder / company: if you are really so good, beat me at my own game, like it has always been on the cracking and the demo scenes.
> I'm slightly impressed by how much you hate a license that gives users perpetual freedom. Also, why do you think that CDDL's weak copyleft is better than GPL? I understand, but don't agree with, people who hate copyleft altogether -- but you only hate the GPL
GPL license attempts to dictate to me what and how I am to do with my own code I write ("you must license all derived work under the GPL").
I do not accept that, even if I firmly believe that open sourcing software is the right thing to do, and believe that open source, free software is the way to go.
> GPL license attempts to dictate to me what and how I am to do with my own code I write ("you must license all derived work under the GPL").
> I do not accept that, even if I firmly believe that open sourcing software is the right thing to do, and believe that open source, free software is the way to go.
The CDDL has the same requirement, except it's file-based. What are you even talking about FFS.
No, that's a pretty standard severability clause that helps the user. It means that if one section of the CDDL is found invalid, users can still use the software. The GPL on the other hand, by refusing to have a severability clause, means that if any part of the GPL, no matter how inconsequential, is found invalid, the entire license is null and void and no one can use it. That intentional omission makes the GPL a much more user-hostile license than it should be.
> No, that's a pretty standard severability clause that helps the user. It means that if one section of the CDDL is found invalid, users can still use the software. The GPL on the other hand, by refusing to have a severability clause, means that if any part of the GPL, no matter how inconsequential, is found invalid, the entire license is null and void and no one can use it. That intentional omission makes the GPL a much more user-hostile license than it should be.
The GPL's severability clause says that the section is invalid, not the whole license. But the CDDL allows for the license to be changed after the fact.
I was incorrect in remembering what the CDDL had if a clause is found to be unenforceable. A reform clause has a lot of overlap with severability. While a contract can be altered in such a case, reform means that the spirit of the unenforceable clause must remain intact. Were it severable, then the entire clause would be excised, potentially altering the license much more through omission.
"By bringing these two companies together we are creating the opportunity to develop and bring to market vertically integrated mobile and IoT services and solutions that deliver extraordinary simplicity and value to our customers."
Given how well React Native tends to work, and I have to be honest, I like the ecosystem structure better than most apps I've worked on in general, I can see it actually working out better in many cases.
Prob not great for more advanced messenger functionality but Face Slim (https://github.com/indywidualny/FaceSlim) does notifications and simple/group chats fairly well.
- AOT compilation for a subset of JS: http://www.eecs.berkeley.edu/Pubs/TechRpts/2015/EECS-2015-13...
Its corporate culture only allows the most cunning, politically savvy person to stay alive and move up the rank, and thus most executives (all if I limit it to small sample of executives I've personally met) fit that model.
And shit literally flows downwards, where goals/promises set by them would be pushed downwards and engineers have to take the burden.
It doesn't help that Korean society is very hierarchal and based on Confucius principles, where you don't usually challenge older persons and/or someone higher in the rank. This is one example that describes serious problem - http://thediplomat.com/2013/07/asiana-airlines-crash-a-cockp....
For those of you who are intrigued and have time, I suggest watching Misaeng with English subtitles (https://www.viki.com/tv/20812c-incomplete-life). Samsung isn't as bad, but the same hierarchy, verbal abuse, social dynamics, and strict rules on paper format exist.
The best outcome would be if they leave Joyent's management and culture alone. But I doubt it.
I also have the first-hand experience of their applying the same "consumer electronics" mentality to completely different business which required high-touch sales.
There is no denying success of Samsung - multi-billion, international corporation. However, Samsung is only good at generating quality hardware products at mass scale. There have not been success in any sort of software and services. Perhaps they are trying to expand beyond their strengths, and I applaud that effort and they actually do need it, since it's only matter of time Chinese companies will catch up and produce as quality products as Samsung, as Samsung did to Sony. I hope it bears fruits. I hope they can allow Joyent to succeed and thrive, and learn from that.
I will see what happens next few years.
"Samsung will immediately benefit from having direct access to Joyent’s technology, leadership and talent. Likewise, Joyent will be able to take advantage of Samsung’s scale of business, global footprint, financial muscle and its brand power."
Their fears have come true (and now it's even happening to Apple). Hardware is an incredibly difficult, risky business, and differentiation is now in the services/software arena. That's why Samsung, in particular, needs this acquisition (and others like it).
Disclaimer: I'm not involved in that space, so maybe they've started?
I don't expect to see Samsung take on GCE, Azure or AWS directly though... and would be really unsure if I were a Joyent customer right now.
That said, since SmartOS is based on illumos, and illumos is designed from the ground up to be portable, running SmartOS on ARM would be cool, since it would open the doors for illumos on embedded devices.
I would so love me an illumos based, iPad Pro-like tablet...
It seems that NodeJS has moved out of Joyent. They have hosted container support that seems to run on solaris, which seems interesting, but a bit too much of buzz-wordy from their website.
I am not very familiar with this, so will be great if someone can explain a little bit. I read the comments around orchestration, but am more interested in Joyent's value proposition.
If anybody deserve it, it's you guys.