no 2016 will be the year where all early adopters of linux will migrate to BSD to take back the control of their computers, and 2017 will be the year of BSD desktop. ;)
Honest question: In what way does Linux give you less control than BSD?
Binary blob drivers are just as necessary on BSD as on Linux. Are you referring to Ubuntu's built-in Amazon searches? Because you can just not use the Unity desktop. If it's building everything from source you're after, there is Arch and Gentoo.
Don't get me wrong, I am a big fan of FreeBSD. I'm just wondering if I'm missing something.
The rant about the kernel could be simple : featuritis or cancer.
In fact I have been working with centOS, feodora, RHEL, debian, ubuntu, mint, mandrake, mandriva, slackware ... the base are becoming messy, and each distros are diverging but (except for mint that is making efforts) they don't seem to care about the user experience.
Not only for the desktop, but also as a coder and sysadmin.
I would call this a linux fatigue.
Bored of trying to make fans works so that my CPU don't burn like it once did after I upgraded ubuntu.
Bored of trying to convince RH supports that their forks are not vanilla package with their messy patch levels without the security ports from upstream are a lie (they work for NSA/GCHQ or what?).
Bored of having to deal with SSH blunders because a packager thought he was a dev.
Bored to recompile python from rpm sources to have a decent python package.
Bored of using virtualenv because the packager think Ksat problems are polynomial problem but makes you ends up with rottenly old packages, while I can pinpoint my packages to the version I want.
Bored of python/perl/latex broken packages "so that it can fit on embedded systems" when minimal base is what? 400MB?
Bored of not being able to have a simple way to choose the options I want for my packages (like pragma, which library) and poor default choices.
Bored of unsecured default cumbersome config for servers that are unsecure and poorly designed (apache cgi-bin was a PITA).
Bored of useless features (GNUeries) like bash as default that augments the surface of vulnerability.
Bored of the whatthousands way of configuring IP.
Bored of 300 ASM likes lines of iptables based on GOTO kind of thinking when pf does it in 30 lines.
Bored of "cloud" containers that don't really do the jobs" when jails are fine.
Bored of caring about security much more than I would like.
Bored of configuring my windows manager every new releases and to lose my configuration or where my close button side is on.
Bored of upstart/systemd just because devs don't know how to handle SIGHUP SIGINT ... and need clutch to not learn the bases.
Bored of having no people trying to describe seriously what they are doing and making no efforts in documentation and engineering docs.
Bored of people replacing technical arguments with the potential coolness of a feature, while throwing RTFM at newcomers.
Bored of people not understanding how computers works.
Bored of the linux based cloud solutions that are as stable as a chaotic system.
Bored of not being able to write my drivers anymore in C, or having a C compiler that works and that no one cares about it.
Bored of the messy C code in the linux kernel that is unreadable.
Bored of having to change distributions because distributions wants to force feed me features or windows manager or because my HW does not work anymore.
Bored of learning again and again where is the F config, how to do this simple network configuration, what is the name of f pakcage where did they put it, in which repo how to get a f* vanilla upstream up to date version of the lib...
Bored of openSSL.
Bored of how much people confusing installing a distro with being an expert at something.
Bored of not being able to do my packages because tools & logics are too complex.
On one hand the author thinks 2016 is the year of concurrency on the web, on the other hand half the article explains the problems with concurrency on the web.
I hope that by concurrency, the author also means "shared address space". Because that is what concurrent programs need (especially for the immutable-data structures, that need to be passed cheaply from one thread to another).
Web workers can win you huge performance boosts. In my work we implemented auto-indexing of client-side resources so you can search without lag or hiccups, and we published a library [0] so that others could use it. Pushing stuff as much stuff as you can to web workers is definitely something that needs to get more love.
This isn't a particularly new idea. Here's a short writeup about this in react-future [1]. Roughly one month ago someone published react-worker-dom [2] and wrote a blog post [3] about it.
But this is ultimately just a workaround for terrible DOM APIs. Maybe I've been living under a rock, but I haven't seen any new DOM API proposals to help deal with these problems. The only new DOM API I've heard about is web components, which still runs in the UI thread. Does shadow DOM win us any huge performance boosts?
In the last few weeks I've looked through the source for a lot of elements in the polymer catalogue [4]. This is probably going to come off as a bit rant-y and negative, and it's totally tangential to the topic, but I'm totally unconvinced that web components are the way forward. These APIs are too complicated and they rely on side-effects which are very difficult to trace and debug. It's code that says: Execute this side-effect and I'm going to hope that now my environment is in an expected state. Oh, you screwed up with a typo? Don't worry, I'll just fail silently, good luck debugging me! You import files and then you pray that it polluted your namespace with the correct globals. This is not an acceptable way for building web apps in 2016.
In contrast, I've been using css-modules [5] for the last few months, and although it has its own shortcomings and problems, I love that it makes it makes your usage very explicit and easy to trace. If you look at the css-modules link, you'll see why it's so great: You're explicitly saying you want to pull in that stylesheet and reference that specific class.
The same goes when you're using React: You import a component and you put it in the render function's return value. If you try rendering something invalid, it'll scream as you. You can debug this much more easily because you know the file that was referenced and the specific export that's being used.
I honestly really hate it when "concurrency is hard" is trotted out as a reason for not using it when using it would very obviously make life better for the end-user.
Is it as straightforward as non-concurrent code? No, obviously it isn't. Is it so mind-bendingly difficult that we need to be paralyzed by fear at the mere mention of concurrency? No, it isn't that either.
There are things you can do to make concurrency easier. Dispatch queues for one eliminate a lot of bugs. Being thoughtful about when and how we use concurrency is another. Race condition bugs are sometimes difficult to track down and cure, but if you understand the basic concepts around concurrency and controls around that they're generally fairly easy to avoid.
The biggest problem I've run into with people is they don't even understand what mutexes, semaphores, condition variables, or atomic variables are or when you'd use each. People don't know what joining a thread is. I ran into a bug at a previous job where they were spawning and destroying threads very quickly (which is a problem, but not their main problem) and instead of using a join to block until a thread's completion they were using sleep(1). Switching to a join sped up their code immensely and improved a data processing operation that previously took months to now taking days.
tl;dr people need to a) read up on how to do concurrency and b) be more thoughtful about the code they're writing when doing it. It's not so scary we should just avoid it altogether, especially when the user experience can be greatly improved by using it. Concurrency is another tool in the toolbag, even if it's a chainsaw without a cover.
I'm not really involved in web development much, my comment was more general though. It's surprising the number of people in an environment where threading is a real option that don't really understand it very well.
The "web" for a long time was Perl/Python/PHP/Ruby. I had never done real concurrency work until I started doing C#/Java. But most web devs I've worked with, especially the ones with an interpreted language background, have no idea or even interest to do any kind of concurrency. NodeJS isn't making things better either.
AFAIK, the only "easy" and pleasant language to do concurrency in is Go and maybe Clojure if you can get past the LISP. C# is nice but is (for now) still too MS-centric, and Java is ...well...Java.
Until we move away from the intercepted languages and frameworks of the 1990's, this won't get any better anytime soon.
> AFAIK, the only "easy" and pleasant language to do concurrency in is Go and maybe Clojure if you can get past the LISP.
Have you looked into Elixir? It's a language that compiles to Erlang's VM and thus has the same concurrency model as Erlang's, which is one of the simplest ones.
Can you suggest a few resources to further this cause? I'd love to write more concurrent code but outside of an OS class, I don't have much experience.
I just hope, that all the javascript anywhere!, everywhere! will stop. Otherwise, I think I will move away from programming. Not a rust, but, boy I do dislike javascript!
I have to use it. There no other way. Please don't tell me coffee script/typescript, future script.
Also, I feel tired, fatigue I will say, every 2 month there a new way of doing stuff. And you know how difficult is to grab a junior and explain that now react is the shit and not more angular?
Also, do you know how difficult is for the company to hire people and we have to tell them: "we are a bored company, we just use jquery, rails and ajax."
I do not have anything with the language. Is becoming better, but I really hate the noise, the billions of libraries, and every two month the `correct way of doing stuff`
As a Junior developer, JavaScript scares the shit out of me. I have been trying to find some basic JavaScript testing framework so we could test if we broke anything when we commit some code changes, and as soon as I tried building PhantomJS/CasperJS (I had to do that on the spare server because compiling them on my machine takes hours), it scared the hell out of me.
> Please don't tell me coffee script/typescript, future script.
Why not? You are already doing a build step for Babel mostly likely. Might as well do ClojureScript, which has simple syntax and one tool that does it all.
Unfortunately the proposal doesn't solve one of the main problems with the mobile web: Battery usage. It doesn't matter if you run all that extraneous js on background threads. It still uses power.
It can be an energy win if the background threads allow work to be completed much faster. That's because finishing earlier will allow CPUs to throttle down as soon as the work is done, thus cutting power usage.
Trying to make it a native platform rather than it's original intended purpose (document sharing and simple data input/retrieval) is where all the issues arise from.
A pretty good read other than all bullet points. I kind of enjoyed the part where he said the initial solution was to not use any Javascript. I think the simple way to make the web great again, you'd have to just use JS sparingly.
Everyone has their own opinion on the web but I tend to think it shines in simplicity, sites such as HN are a good example of that. Let the browser do what it can and forget the rest.
The rise of web apps and app stores show that distribution is everything.
You can complain that this isn't what a browser is for, but it won't really matter until you can distribute your favorite kind of software in a way that requires (nearly) zero effort and zero risk for your end users to get started with.
An appstore program that costs nothing up front is the same amount of effort as opening a webpage, but with less risk.
Open browser->type in appname->hit enter
Open appstore->type in appname->tap install (with what is likely to be less risk since it's not only sandboxed but also at least Apple's appstore is inspected)
If distribution is king, you're going to get more eyeballs from people browsing in an appstore than sitting out there at www.urlhere.com. Where you'd have to actively advertise in some fashion.
I stand by the viewpoint that all these issues that arise from misusing a tool. And the author isn't too far offbase either. As noted, a 10MB page is ridiculous and it sounds to me that should be in an appstore somewhere. That's just misuse of the platform and far off what was the intended purpose.
> This actually happens: You thought it was a cool hack someone wrote a H264 decoder in pure JavaScript? Ads use that to implement auto play video where it would be not allowed by the browser.
See, the problem is just bloat. Things will just get bigger until you push back. If you enable "bigger" with various optimizations (15 analytics trackers are now just as heavy as 1!) then they'll just get even bigger (33000 analytics trackers !?) because that's just what happens in business settings. Things will just get worse until it's a problem again, and then maybe you'll have justification to do something about it. We're always stuck on the edge of "not quite so bad I swear off news and product websites entirely".
I have run into the same "multi-threading is hard" attitude among younger programmers. I believe that kind of attitude to be a career limiting mistake. In the interests of scalability, you may have to accommodate multi-process oriented concurrency anyway with such as techniques as message brokering, or CAS style counters available in various databases; however, it is always going to be cheaper to manage a pool of threads in a single process than to manage a pool of processes. In the data center, most bare metal servers have lots of cores where multi-threading really shines. I have noticed a trend in AWS to offer more single vCPU EC2 instance types for those unwilling to learn the joys of thread pool executors and linked blocking queues.
36 comments
[ 4.2 ms ] story [ 74.6 ms ] threadBinary blob drivers are just as necessary on BSD as on Linux. Are you referring to Ubuntu's built-in Amazon searches? Because you can just not use the Unity desktop. If it's building everything from source you're after, there is Arch and Gentoo.
Don't get me wrong, I am a big fan of FreeBSD. I'm just wondering if I'm missing something.
The rant about the kernel could be simple : featuritis or cancer.
In fact I have been working with centOS, feodora, RHEL, debian, ubuntu, mint, mandrake, mandriva, slackware ... the base are becoming messy, and each distros are diverging but (except for mint that is making efforts) they don't seem to care about the user experience.
Not only for the desktop, but also as a coder and sysadmin.
I would call this a linux fatigue.
Bored of trying to make fans works so that my CPU don't burn like it once did after I upgraded ubuntu.
Bored of trying to convince RH supports that their forks are not vanilla package with their messy patch levels without the security ports from upstream are a lie (they work for NSA/GCHQ or what?).
Bored of having to deal with SSH blunders because a packager thought he was a dev.
Bored to recompile python from rpm sources to have a decent python package.
Bored of using virtualenv because the packager think Ksat problems are polynomial problem but makes you ends up with rottenly old packages, while I can pinpoint my packages to the version I want.
Bored of python/perl/latex broken packages "so that it can fit on embedded systems" when minimal base is what? 400MB?
Bored of not being able to have a simple way to choose the options I want for my packages (like pragma, which library) and poor default choices.
Bored of unsecured default cumbersome config for servers that are unsecure and poorly designed (apache cgi-bin was a PITA).
Bored of useless features (GNUeries) like bash as default that augments the surface of vulnerability.
Bored of the whatthousands way of configuring IP.
Bored of 300 ASM likes lines of iptables based on GOTO kind of thinking when pf does it in 30 lines.
Bored of "cloud" containers that don't really do the jobs" when jails are fine.
Bored of caring about security much more than I would like.
Bored of configuring my windows manager every new releases and to lose my configuration or where my close button side is on.
Bored of upstart/systemd just because devs don't know how to handle SIGHUP SIGINT ... and need clutch to not learn the bases.
Bored of having no people trying to describe seriously what they are doing and making no efforts in documentation and engineering docs.
Bored of people replacing technical arguments with the potential coolness of a feature, while throwing RTFM at newcomers.
Bored of people not understanding how computers works.
Bored of the linux based cloud solutions that are as stable as a chaotic system.
Bored of not being able to write my drivers anymore in C, or having a C compiler that works and that no one cares about it.
Bored of the messy C code in the linux kernel that is unreadable.
Bored of having to change distributions because distributions wants to force feed me features or windows manager or because my HW does not work anymore.
Bored of learning again and again where is the F config, how to do this simple network configuration, what is the name of f pakcage where did they put it, in which repo how to get a f* vanilla upstream up to date version of the lib...
Bored of openSSL.
Bored of how much people confusing installing a distro with being an expert at something.
Bored of not being able to do my packages because tools & logics are too complex.
Bored of not being able to audit anything.
Bored of the community above all.
This isn't a particularly new idea. Here's a short writeup about this in react-future [1]. Roughly one month ago someone published react-worker-dom [2] and wrote a blog post [3] about it.
But this is ultimately just a workaround for terrible DOM APIs. Maybe I've been living under a rock, but I haven't seen any new DOM API proposals to help deal with these problems. The only new DOM API I've heard about is web components, which still runs in the UI thread. Does shadow DOM win us any huge performance boosts?
In the last few weeks I've looked through the source for a lot of elements in the polymer catalogue [4]. This is probably going to come off as a bit rant-y and negative, and it's totally tangential to the topic, but I'm totally unconvinced that web components are the way forward. These APIs are too complicated and they rely on side-effects which are very difficult to trace and debug. It's code that says: Execute this side-effect and I'm going to hope that now my environment is in an expected state. Oh, you screwed up with a typo? Don't worry, I'll just fail silently, good luck debugging me! You import files and then you pray that it polluted your namespace with the correct globals. This is not an acceptable way for building web apps in 2016.
In contrast, I've been using css-modules [5] for the last few months, and although it has its own shortcomings and problems, I love that it makes it makes your usage very explicit and easy to trace. If you look at the css-modules link, you'll see why it's so great: You're explicitly saying you want to pull in that stylesheet and reference that specific class.
The same goes when you're using React: You import a component and you put it in the render function's return value. If you try rendering something invalid, it'll scream as you. You can debug this much more easily because you know the file that was referenced and the specific export that's being used.
[0] https://treasure-data.github.io/redux-search/
[1] https://github.com/reactjs/react-future/tree/master/05%20-%2...
[2] https://github.com/web-perf/react-worker-dom
[3] http://blog.nparashuram.com/2015/12/react-web-worker-rendere...
[4] https://elements.polymer-project.org/
[5] https://github.com/css-modules/css-modules#css-modules
Is it as straightforward as non-concurrent code? No, obviously it isn't. Is it so mind-bendingly difficult that we need to be paralyzed by fear at the mere mention of concurrency? No, it isn't that either.
There are things you can do to make concurrency easier. Dispatch queues for one eliminate a lot of bugs. Being thoughtful about when and how we use concurrency is another. Race condition bugs are sometimes difficult to track down and cure, but if you understand the basic concepts around concurrency and controls around that they're generally fairly easy to avoid.
The biggest problem I've run into with people is they don't even understand what mutexes, semaphores, condition variables, or atomic variables are or when you'd use each. People don't know what joining a thread is. I ran into a bug at a previous job where they were spawning and destroying threads very quickly (which is a problem, but not their main problem) and instead of using a join to block until a thread's completion they were using sleep(1). Switching to a join sped up their code immensely and improved a data processing operation that previously took months to now taking days.
tl;dr people need to a) read up on how to do concurrency and b) be more thoughtful about the code they're writing when doing it. It's not so scary we should just avoid it altogether, especially when the user experience can be greatly improved by using it. Concurrency is another tool in the toolbag, even if it's a chainsaw without a cover.
Either that or your comment is not in regard to web development at all?
Certainly some teams are more sophisticated than others and can achieve a higher level of site design.
AFAIK, the only "easy" and pleasant language to do concurrency in is Go and maybe Clojure if you can get past the LISP. C# is nice but is (for now) still too MS-centric, and Java is ...well...Java.
Until we move away from the intercepted languages and frameworks of the 1990's, this won't get any better anytime soon.
Have you looked into Elixir? It's a language that compiles to Erlang's VM and thus has the same concurrency model as Erlang's, which is one of the simplest ones.
Can you suggest a few resources to further this cause? I'd love to write more concurrent code but outside of an OS class, I don't have much experience.
Thanks!
http://www.amazon.com/Java-Concurrency-Practice-Brian-Goetz/...
and it'd be a good start. It's in "boring" old Java, but it goes over a lot of the meat and potatoes concepts.
Also understand this code: http://en.cppreference.com/w/cpp/thread/condition_variable
Also, do you know how difficult is for the company to hire people and we have to tell them: "we are a bored company, we just use jquery, rails and ajax."
I do not have anything with the language. Is becoming better, but I really hate the noise, the billions of libraries, and every two month the `correct way of doing stuff`
end of rant :)
As a Junior developer, JavaScript scares the shit out of me. I have been trying to find some basic JavaScript testing framework so we could test if we broke anything when we commit some code changes, and as soon as I tried building PhantomJS/CasperJS (I had to do that on the spare server because compiling them on my machine takes hours), it scared the hell out of me.
Why not? You are already doing a build step for Babel mostly likely. Might as well do ClojureScript, which has simple syntax and one tool that does it all.
A pretty good read other than all bullet points. I kind of enjoyed the part where he said the initial solution was to not use any Javascript. I think the simple way to make the web great again, you'd have to just use JS sparingly.
Everyone has their own opinion on the web but I tend to think it shines in simplicity, sites such as HN are a good example of that. Let the browser do what it can and forget the rest.
You can complain that this isn't what a browser is for, but it won't really matter until you can distribute your favorite kind of software in a way that requires (nearly) zero effort and zero risk for your end users to get started with.
Open browser->type in appname->hit enter
Open appstore->type in appname->tap install (with what is likely to be less risk since it's not only sandboxed but also at least Apple's appstore is inspected)
If distribution is king, you're going to get more eyeballs from people browsing in an appstore than sitting out there at www.urlhere.com. Where you'd have to actively advertise in some fashion.
I stand by the viewpoint that all these issues that arise from misusing a tool. And the author isn't too far offbase either. As noted, a 10MB page is ridiculous and it sounds to me that should be in an appstore somewhere. That's just misuse of the platform and far off what was the intended purpose.
See, the problem is just bloat. Things will just get bigger until you push back. If you enable "bigger" with various optimizations (15 analytics trackers are now just as heavy as 1!) then they'll just get even bigger (33000 analytics trackers !?) because that's just what happens in business settings. Things will just get worse until it's a problem again, and then maybe you'll have justification to do something about it. We're always stuck on the edge of "not quite so bad I swear off news and product websites entirely".