The Affect of Minimum Wage on the Recession - <AUTHOR> http://jeffspost.wordpress.com/2008/12/18/the-affect-of-minimum-wage-on-the-recession/

<comment><USER2> s/affect/effect/

I know, you already knew that. But if nothing was said, we would descend into chaos.

<comment><USER3> Know ye verbs!</comment></comment>


Ask HN: What does "prepare for cyber attacks" mean in context of Middle East? - <AUTHOR> We struck the head of the Iran Revolutionary Guard (and other things).  The papers say brace for cyber warfare.<p>To the layman, what should one worry about? <comment><USER2> Unless you manage large enterprise IT - not much. Do the usual things: ensure backups are running, update software. For a consumer, it doesn't matter if their laptop stopped working because of spilled water, or someone hacking them, and the steps to recovery are the same.

Larger orgs, especially related to infrastructure or national services may be specifically targetted. They know what their weak points are. Phishing, DoS, customer information leaks, ... But what they're afraid of and how they deal with that is going to be specific to their systems. I guess the only common thing for "brace for cyber warfare" is - talk to your peers about weird new things you see.

<comment><USER3> If to the layman, "brace for cyberattacks" means essentially nothing, why issue that as a general warning?

My suspicion is that warnings about cyberattacks are going to be the new "credible threat of terrorism", i.e. a way to fearmonger at the uppermost levels of government in order to raise support for "kinetic warfare", but I hope not.</comment></comment>


The Fast Track to Start-Up Life - <AUTHOR> http://www.inc.com/jessica-stillman/the-fast-track-to-start-up-life.html

<comment><USER2> > Already a veteran of several start-ups at the tender age of 17

> Groom attended Dev Bootcamp straight out of high school, skipping college to > move to Silicon Valley.

On the other hand, college could be pretty useful if you aren't already selling startups in high school...

<comment><USER3> From a career perspective, I believe not going to college was the best choice I could have made. Not even for the startup life, just the regular 9-5. From a personal growth perspective though, I probably missed out on a lot.

It's impossible to have everything in life. I optimized for my career, but those who optimize for other areas of their life are to be respected too. The hard part is figuring out what you want from life straight out of high school, with very little real-world experience.

<comment><USER4> The idea of someone _skipping a CS degree_ to learn some Ruby on Rails and start as a web developer makes me ill. It's classic short-term thinking: web development (in Rails, in particular) is today's hotness, but tomorrow it'll be something else. Since I've started coding, I've watched the waxing and waning of so many technology hype cycles that it makes me dizzy: Hypercard, Visual Basic, C, C++, Java, Win32, Windows MFC, Perl, PHP, Flash, Flex...and now iOS, Android, Javascript, etc. And you know what? This, too, shall pass. For every New Hotness, there's and Old Hotness, and there will be fans of the New Hotness who will be making fun of the cult of the Old Hotness, and how its vision of the future was laughably wrong. This is as predictable as the seasons.

Deep knowledge of general CS concepts -- the things emphasized by a good CS program -- are what allow an engineer to survive the fad-driven cycles that dominate this industry. Because ultimately, there's _always_ a new generation of cheap, bright-eyed, bushy-tailed 20-somethings who know the latest fad better than you do. Yet there are surprisingly few people who can create new recommendation algorithms or build massively parallel systems that scale to thousands of nodes without downtime.

Nearly everyone who complains about CS degrees being a waste of time is complaining that college isn't a vocational school. And, it's not -- but that's a feature, not a bug.

<comment><USER5> _Deep knowledge of general CS concepts -- the things emphasized by a good CS program -- are what allow an engineer to survive the fad-driven cycles that dominate this industry._

I don't believe so. I never studied CS at college, but have had no trouble learning new languages. I cannot write recommendation algorithms (though I'd wager that I could set up a massively parallel system using existing tools), but not every programmer needs to.

I don't doubt that a CS graduate is a better programmer than I am, but it's disingenuous to suggest that a non-CS grad will be unable to keep up with the industry. It just isn't true.

<comment><USER4> So you're arguing that you don't need to know anything more than a steady stream of new languages to survive? That's not a matter of belief -- there's ample evidence to the contrary. The knowledge requirements for industry programmers has been rising steadily for as long as I've been coding.

"Web developer" is today's equivalent of "Visual Basic programmer" in the early 90s. Those kinds of jobs will always exist, but they'll be increasingly marginalized -- just as they have been since the early 90s.

I expected someone to argue that university isn't necessary to learn CS. I didn't expect someone to argue that CS knowledge isn't necessary to have a career in software. Yikes. Whither hacker news?

<comment><USER6> I can't really take anyone seriously who says a _"Web developer" is today's equivalent of "Visual Basic programmer"_. The problem with visual basic came when people start drag dropping things together, which isn't even what rails is about.

I would also bet heavily that the number of programmming jobs needing low levels of CS knowledge but high levels of complexity management are growing at a great, great rate compared to jobs requiring high levels of CS knowledge.

Marginalized? I think not. That 20 people with a mere 8 weeks programming experience, people who will be relatively useless at programming for another year or so, are in such great demand says everything.

<comment><USER4> _"I can't really take anyone seriously who says a "Web developer" is today's equivalent of "Visual Basic programmer". The problem with visual basic came when people start drag dropping things together, which isn't even what rails is about."_

That isn't what Visual Basic was "about", either. But in practice, most professional VB developers made UIs that interacted with enterprise database systems. Otherwise known as: CRUD apps.

Actually, to the extent that the vast majority of today's "web developers" are building web interfaces to a database (which they are), the tools were probably more advanced in 1990 than they are today. Hypercard and VB were far easier platforms for "programmers" with shallow CS knowledge to build enterprise systems.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> How was he able to start an immigration process without a university degree? Was it because he is from Australia and not, say, Brazil? I'd love to move to the US as well, but without a degree that's basically impossible for me.

<comment><AUTHOR> Actually, the process is just getting started. I'm looking into a variety of paths, but I'm not going to 'really' start the process till I'm 18. From there I will likely go a J-1 route.

I would love the O-1, but I'm afraid I don't yet have enough press coverage, or letters of recommendation. Working on it.

</comment></comment><comment><USER8>
        88% of Groom's fellow students currently have job offers on the table, with approximately 60% of those headed to start-ups and the remaining 40% mostly employed at consultancies.

If the total group size is 20, why not use actual numbers rather than percentages? I know it sounds like more using percentages, but it feels a little misleading to me.

edit: formatting.

<comment><AUTHOR> Because 3 of the 20 were not looking for jobs. Thus it would not have made sense to use them in assessing the success.

I'm Lachy Groom, btw.

<comment><USER8> I think that's a good enough reason to not include them in the stats, but I find the use of percentages confusing over simply the raw numbers?

20 People. 3 Not Looking, so removed. It mentions your fellow students, so minus 1 more and we're down to sample size of 16. 88% of 16 is 14.08 - 14.08 people is a weird number. Maybe the maths was done including yourself, so that'd be 17... which gives us 14.96 people - so that doesn't make sense either?!?

Surely something like "Out of his fellow students 16 were looking for, and have job offers on the table. 10 of whom are headed to startups, with the other 6 mostly employed at consultancies." My numbers aren't accurate, but I think the sentence is much clearer.

This is an aside though, congrats on being brave enough to go off to another country to do this - never an easy choice, though sometimes here on HN it comes across as not-a-big-deal.

<comment><AUTHOR> We provided the author of this story, and all other stories all the numbers. I guess the percentages just are easier to write about!

Thanks for the compliment! It was a crazy ride.

</comment></comment></comment></comment><comment><USER9> Is there anything like this for Django?

<comment><USER10> I would be very surprised to see it. This school is an outgrowth of the unusual demand for Rails-specific talent amongst VC-oriented startups in SV and NYC. Django has maybe a third [1] of the cachet of presence in that particular niche. Note that this is not intended as a statement of the relative merits of the two frameworks.

[1] I got those numbers by skimming the last six "Who's Hiring?" threads.

<comment><USER11> What "who's Hiring" threads? Can you link me? (still new to HN)

<comment><USER10> <http://news.ycombinator.com/submitted?id=whoishiring>

</comment></comment></comment></comment><comment><USER12> What would living expenses be like in SF for 10 weeks?

<comment><USER13> I'd budget like $1000-$1200/ month. I paid $900/month just for rent when I went through the program. And eating at restaurants is an easy $20/day on the low-low end. $20*30 = $600/month. That's already $1500/month. If you're really diligent, you can cut a lot of the food cost by going to 2-3 meetups every week and getting free meals. Or eating the $5 special at Subway every single day every single meal like I did. (I may never eat a Tuna Jalapeno sub again in my life.)

</comment></comment><comment><USER14> Good one ! You're an example Lachy</comment>


Your hard drive is too big - <AUTHOR> http://www.stefankendall.com/2011/12/17/your-hard-drive-is-too-big/

<comment><USER2> Unnecessarily trollish.

A 1TB, 7200RPM drive costs like 100 bucks nowadays. At that price being able to store large amounts of crap is hardly a giant waste. Half the folks I know have burned that much money on collecting cases for their iPhones. For that matter, it might not even be necessary. Me, I've got a couple big disks, because my test data sets alone consume nearly a terabyte.

Second, I agree that having an SSD can be really beneficial. Which is why I got one. But that doesn't imply that the presence of a 1TB drive is harmful. It's absolutely OK to have both. Even a good idea, since they have different strengths. SSDs certainly have great bandwidth and latency, but price per gig is another metric that's worth considering.

For that matter, if most the work you're doing is CPU-bound and the software you work on already compiles in a second or two, there's a chance that an SSD doesn't really provide much value anyway. Booting might take longer, but any reduction in boot time below how long it takes to get my morning coffee is meaningless.

<comment><AUTHOR> Price per GB is a crap metric; price per _used_ GB would be more relevant. If your test data is terabytes, you externalize to servers or lock yourself into only being able to work off a desktop. I also question whether or not a subset of that data could be run locally, and the CI system could run a full stack.

This just sounds like a justification of a bad test environment.

I also can't think of any project that compiles "in a second or two". Compilation and tests usually run build time into the minutes quickly, and time grows linearly, or possibly superlinearly with a project assuming even mild test coverage.

If you're locked into a desktop, you're locked into a network, and you can stick big data on a NAS or centralized server for re-use and testing. Or do you copy and paste the terabyte of data to every new developer?

<comment><USER2> The latency and bandwith of a hard disk is unacceptable, but then you suggest using a NAS instead?

Interesting.

</comment></comment></comment><comment><USER3>
        $ iostat -kx sda sdb sdc sdd
        Linux 3.1.0-1-amd64 (Zia)       12/19/2011      _x86_64_        (8 CPU)

        avg-cpu:  %user   %nice %system %iowait  %steal   %idle
                   0.93    0.02    0.72    0.25    0.00   98.08

        Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
        sdb               7.41     2.00    1.48    5.06   547.46    67.40   188.21     0.31   46.80  129.57   22.66   7.51   4.91
        sdc               7.40     2.01    1.47    5.16   547.20    77.23   188.43     0.33   50.02  164.44   17.34   6.75   4.47
        sdd               7.42     1.87    1.42    4.51   546.97    45.87   199.69     0.39   65.07  211.90   18.71   7.67   4.55
        sda               7.37     1.86    1.46    4.42   546.57    36.04   198.25     0.26   43.54  122.63   17.52   7.18   4.22

OK, that's 4 7200 RPM SATA disks, definitely not SSDs. They're in RAID10, so definitely better than 1 drive, but still, all under 5% utilization.

Big builds, etc. pretty much are CPU bound, even on a quad-core i7.

That's true on my single 5400 RPM disk laptop, too (though it has a much slower CPU).

These both run Linux—maybe Windows has ineffective disk caching; I don't know. But please avoid calling people who have actually bothered to measure such things and make decisions on it "fucking idiots".

(Disclaimer: no ridiculously expensive graphics cards here)

</comment><comment><USER4> The title really should be 'Your hard drive is the bottleneck/too slow, spend money here for an SSD'

My work laptop came with a 5400rpm 750gb drive, however they provide a stipend for hardware/software I need. First thing I did, 120gb SSD, optibay (removed optical drive, put 750gb drive there), and 8gb of RAM (not near as important, especially with an SSD, but still cheap).

<comment><USER5> Exactly. I've spent about $1600 so far on this PC, I have 6 hard drives and about 7 TB of disk space (plus 2x1TB external drives). One of those drives is an SSD, so all my programs launch fast and the documents I'm working with all open and compile quickly.

</comment></comment><comment><USER6> Yes, I am a developer. I'm also a photographer. I shoot in raw. Therefore this argument is invalid. When Macbooks can have dual hard drives, then this will make sense.

<comment><USER7> Oh but they can. <http://www.mcetech.com/optibay/>

<comment><USER6> Awesome.

</comment></comment></comment><comment><USER8> I have burned through 8 SSDs in VM hosts. Using TRIM. I am not ready to trust them yet.</comment>


What are the best books you have read in 2018 and would recommend? - <AUTHOR> <comment><USER2> 'A House for Mr. Biswas' by V.S Naipaul - Beautiful book in every way. I can't remember the last time I read a book this good. I'd read most of his shorter books before but never finished this one for one reason or another. I'm glad I did.

'Shira' by Shmuel Yosef Agnon - Was introduced to Agnon by an old friend. Having not read any major works by Israeli writers(especially those set in early 201th century Israel), I found this book to be very beautiful also. Did read some of his other material, a collection of short stories. Hope to dive in further when time permits.</comment>


Dog Bites Man; Pope Condemns Violence; Publishing Still Doesn't Get It - <AUTHOR> http://techcrunch.com/2011/11/19/publishing-still-doesnt-get-it/

<comment><USER2> I attended a video games conference here in Australia last week. There was an interesting session about the pro's and con's of using a publisher in the mobile space.

I learnt that they don't pay large advances, you have to develop your game first, nor will they put a marketing spend in writing, they want to see how the game will do first.

As far as I can tell, the only reason you would work with them is that they have the phone number of the guy in charge of the app store and can call him and beg for your app to be featured.

This piece reminded me of it because I think these print guys need to have a look at what a traditional publisher is actually going to do for them. How much marketing money are they going to spend? How are they going to get your book in front of people? How much risk are they willing to take for their share of the success.

You have to look at what you actual want a publisher to do for you, and make sure they deliver. You can't just go to them because "that's how its always been".

</comment><comment><USER2> I have another observation. Some more notes about what an author might learn from and indie game developer.

Seems pretty clear to me is that free games won the war in the App Store. Most of top grossing games in the app store right now are free with in some kind of in app purchases.

I think it's safe to say that free is where the eBook store will be going as well. You might as well be the first and take advantage of it.

Mr Evans tells us that people want subscriptions. I would argue people want free.

So how to you give a book a way for free and still make a living. Some ideas..

1\. Make it really easy to buy small short stories in the same world or extra little bits and pieces. $1 or $2 bucks for a few extra chapters?

2\. Give your true fans, your whales, something to spend a lot of money on. Don't be shy about asking for $500 for a signed hardcover you bound and print yourself 3 months for the eBook version is available.

3\. Sell add space in you books. If you have eye balls, somebody will pay for them.</comment>


Against Life Without Parole - <AUTHOR> https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3172899 <comment><USER2> Especially in non-controversial cases, there's a lot to be said for fixing the problem once and for all.</comment>


Key Access Justifications: a new level of control and visibility for the cloud - <AUTHOR> https://cloud.google.com/blog/products/identity-security/control-access-to-gcp-data-with-key-access-justifications <comment><AUTHOR> The teams at Google, Ionic Security, and many major enterprises spent a considerable amount of time enabling this scenario.

More details can be found in our blog about the launch: [https://ionic.com/customer-managed-trust-in-the-cloud- made-s...](https://ionic.com/customer-managed-trust-in-the-cloud-made-simple- by-google-and-ionic-security/)

Happy to answer any questions here as well.</comment>


Login and unlock in GNOME Shell 3.36 - <AUTHOR> https://blogs.gnome.org/shell-dev/2020/02/18/login-and-unlock-in-gnome-shell-3-36/ <comment><USER2> This is really great work, but I still miss my quirky xscreensavers.</comment>


Facebook misses on topline in Q2; stock crashes 7.5% - <AUTHOR> https://news.alphastreet.com/facebook-earnings-q2-2018/ <comment><USER2> The article has changed its title to "Facebook misses on topline in Q2; stock crashes 7.5%" now, kind of funny that it's almost the opposite of the original one (and the article text still sounds very positive).

<comment><USER3> For those curious the original was a triumphant: "Facebook is invincible, tops Q2 estimate despite controversy".</comment></comment>


Ruby Scales, and It's Fast – If You Do It Right - <AUTHOR> http://www.engineyard.com/blog/2010/architecture-wins-varnish-and-more/

<comment><USER3> I don't think anyone seriously argues that it's impossible to scale Ruby websites, and make them run quickly with caching and various optimizations.

Rather, the trouble with Ruby (and Rails) is that you end up having to implement these optimizations much faster than with a lighter-weight setup (like PHP on top of a vanilla database, with no ORM).

Hence all the discussion about your "stack", middleware, load-balancing, front-end servers, merbs, mongrels, passengers, and all the bewildering variety of gems required for the care and feeding of a production app. Rails developers write about armoring their app with all this extra stuff in a way reminiscent of MMORPG players equipping a character for battle.

It's a legitimate trade-off, and many people seem comfortable making it. But posts like this sidestep the issue. It's not that Ruby can't scale, is that Ruby makes you fuss over scaling right away.

<comment><USER4> Well, "right away" is kind of misleading. If you're the average company making a Rails website, you'll get by with common-sense optimizations, database indexes and the like that you'd have to do in PHP anyways. I've worked on probably a dozen Rails apps and have only ever had to resort to horizontal scaling and memcached once.

I think the key is that developing the app and scaling the app can be separate tasks. If you do it right, for the lion's share of your app code is still focused on the app, and all the caching and whatnot is handled elsewhere. In PHP, if you had to use memcached it would be a massive change that would touch every corner of your codebase. In Rails, you'd use a plugin and maybe a few filters and you'd be good to go.

<comment><USER3> I think that's a good description of the tradeoff. At some point, the filters, plugins, middleware and so on that let you focus your energies on the app begin to interact in non-trivial ways, and so the time you spent not having to worry about them during development gets repaid worrying about them in deployment.

</comment></comment></comment><comment><USER5> ... and if you only ever make one request, from one user, over and over and over again.

        ab -n 10000 -c 1 -C '_redmine_session=9ec759408f1ae3c6f919e50baba5a3dc; path=/' http://127.0.0.1/
        Requests per second:    2839.37 [#/sec] (mean)
        Time per request:       0.352 [ms] (mean)
        Time per request:       0.352 [ms] (mean, across all concurrent requests)

This is an extremely unrealistic workload. It's the best possible scenario for your caches. Yes, he says he was also browsing and editing the site at the same time, but that's still nothing like modeling the real effects of cache invalidation & overflow from many concurrently users.

<comment><USER6> Seriously... any _real_ load test, IMHO, needs to stem from a capture and replay of live production traffic. Especially if it involves a cache somewhere.

</comment></comment><comment><USER7> I don't like this at all. "Scaling" usually refers to how easy it is to just add more hardware to the problem.

But the thing that really irks me is the discussion of caching reverse proxies and partial page caching. Those optimization techniques are language independent. While I came to the same conclusions about usually needing these with Ruby, I fully recognize that it's much slower at running complex application logic and doing in-memory operations than other languages like PHP, Java, and even Python.

Instead of arguing that Ruby isn't slow (because it is), I would have argued that the time to build and debug a Ruby app is less than it would have been using other languages. Extensive library support, an active user community, many great tutorials / code snippets, no need to compile, and a pretty flexible syntax make Ruby great for quick development. But let's not pretend we can have our Ruby cake and eat it too.

<comment><USER8> Do you have anything to back that up? An implementor of a PHP static compiler commented that the PHP runtime is horribly inefficient and is only able to appear fast in practice because the majority of the standard library is written in C. If you compare Ruby 1.9 to PHP on the Alioth tests at [http://shootout.alioth.debian.org/u32/benchmark.php?test=all...](http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=yarv&lang2=php), Ruby is very comparable in both memory and cPU usage and scores slightly higher overall, beating out PHP. MacRuby and Rubinius are eventually going to push Ruby performance even further, and right now JRuby already improves CPU performance over the standard runtime.

Rails as a framework may do some inefficient things, and I've heard that the next version of rails will address many of these inefficiencies, but as a language runtime Ruby isn't any sloppier performance-wise than PHP and might even already be better at this point.

<comment><USER9> > If you compare Ruby 1.9 to PHP...

1) "Ruby Scales, and It's Fast" makes a point of talking about MRI not Yarv.

2) The fastest of those PHP programs relative to Ruby 1.9 (n-body and mandelbrot) don't seem to make any use of the PHP standard library - <USER2> undermines your "library is written in C" point.

3) If you look at the quad-core measurements you'll see PHP but you won't see Ruby 1.9 or MRI because (unlike PHP) no one has contributed Ruby programs that can make use of more than one processor.

[http://shootout.alioth.debian.org/u32q/benchmark.php?test=al...](http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=php&lang2=jruby)

</comment></comment></comment><comment><USER10> If Ruby developers would stop trying to debunk the "Ruby and/or Rails doesn't scale" myth, I think the rest of us would forget there was ever an issue. Scaling a web app is language independent, and writing inefficient code is also language independent.

</comment><comment><USER11> I can't see why he used a single webrick process for testing this. It's widely accepted that webrick should never be used in a production environment, so this is a somewhat unrealistic test.

<comment><USER12> I used it because it's slow. Because the speed of Redmine running on webrick isn't the point. The points are A) you can write some really fast stuff that runs in Ruby, and B) if you do some prudent things like think about how to use caching in front of your app, even a really slow app can effectively be very fast when viewed from the outside.</comment></comment>


Why I love Common Lisp and hate Java (2012) - <AUTHOR> https://kuomarc.wordpress.com/2012/01/27/why-i-love-common-lisp-and-hate-java/ <comment><USER2> It is a recurring theme for people to point out how verbose a hello world program is in Java:

        class HelloWorldApp {
            public static void main(String[] args) {
                System.out.println("Hello World!");
            }
        }

For argument sake, let's compare it not to Lisp but to Python instead:

        print("Hello World!")

Once you get proficient in a language and start writing larger programs, your perspective can change entirely. What appears to be verbose in the Java version starts to make sense. For example:

* In Java the top level only contains classes and interfaces. All functions must be put inside a class, and I believe this design simplifies conceptual understanding. Whereas in Python, you have a distinction between top-level variables and functions versus fields and methods bound in classes.

* Python always executes the top level, so you end up with awkward idioms like: if __name__ == "__main__": main(sys.argv)

* Static typing versus dynamic typing. We all know this debate, so I won't repeat it. (This is regarding void and String[].)

* The "public" keyword might seem like noise, but in Python you denote private by prefixing the name with one or two underscores.

* Do you really want print() to be so easily accessible in the top-level namespace? It seems to me that the bigger an application gets, the worse it is to easily litter the codebase with print statements.

* You still eventually need to learn what "@staticmethod" means in Python. Java just forces this learning early on.

<comment><USER3> Totally agree with you - I like Java precisely because it's so verbose. I'd rather have to type 20% more than spend 20% more time figuring out other people's code.

And honestly, I always feel that the Hello World example is kind of biased. It's more an example of Java's way of launching a program being verbose because every program requires a certain minimal structure. But for the rest of the entire Java language that's not the main method, the only real "verbosity" comes from having to declare types, which is pretty much just a requirement of statically typed language and isn't so specific to Java itself.

I've written reasonably large amounts of code in Python, Javascript, Ruby, Racket, StandardML, etc. Every language has its own little forms of "beauty" \- chunks of code that are particularly short and pretty to write in those languages. And I do get a certain amount of satisfaction doing trickier operations in a couple lines in languages like Python. But I always end up preferring Java's more verbose style because I don't want to have to think about the correct syntax to maximize my code's stylishness.

<comment><USER2> I would say that Java has ~50% more code than Python due to types and braces. But I agree with you that it's worth it, because the compiler can check that a programmer satisfied a constraint, instead of relying on informal conventions or comments.

You can have a statically typed language without verbosity, via type inference (Haskell, newer Java, etc.). I wouldn't say I enjoy Java's verbosity, but I would take this over shooting myself in the foot because Python does little to protect me from my own silly type/name mistakes.

I do lament that Java falls short on being able to declare tuples, lists, and dictionaries easily.

<comment><USER4> Most Haskellers write out the types even though they can be inferred. In a pure language, signatures are extremely close to documentation (you know exactly what a function will do by its signature).

Java requires more code than Python or Haskell because it's extremely imperative and statement based. Python on the other hand includes a lot of functional, more expressive idioms like concise list comprehensions.

<comment><USER5> Types aren't documentation, no matter how many Haskell users delude themselves thinking it is.

Documentation is more than a function definition. Types don't explain rationales and how to use functions and programs. Types don't give proper examples.

<comment><USER6> Types are really good documentation. I can tell I'm not deluded by thinking so because I can sit down with a Haskell library containing zero examples and _write code that uses it_. If your assertion was correct, that would be impossible. But it's not only possible, it's easy. Perhaps there is more to types than you realize.

<comment><AUTHOR> Alice: Hey Bob, want to try my nifty new function?

Bob: Sure, Alice, what does it do?

Alice: It takes an object and it returns an object.

Bob: But what does it actually do?

Alice: I told you. It takes an object and it returns an object.

Bob: But what does it do with the object? What's it for? Why should I use it?

Alice: Hey, I just gave you the full documentation for my function. You have everything you need. Now go use it.

Bob: Um, no thanks. I like to know more about what I'm getting myself in to.

<comment><USER7> Thankfully, Haskell supports much nicer types than only `Object`

<comment><USER8> Alice: Hey Bob, want to try my nifty new function?

Bob: Sure, Alice, what does it do?

Alice: It takes a string and it returns an integer.

Bob: But what does it actually do?

Alice: I told you. It takes a string and it returns an integer.

Bob: But what does it do with the string? What's it for? Why should I use it?

Alice: Hey, I just gave you the full documentation for my function. You have everything you need. Now go use it.

Bob: Um, no thanks. I like to know more about what I'm getting myself in to.

<comment><USER4> I think you're criticizing a language you have no experience in. Haskell development is type driven. You start by defining and constraining your types until you get a DSL to write signatures in. See the Idris O'reilly book for more on type driven development.

By the time you've added type constrains through typeclasses, selected types named after the domain, and selected a suitable name for the function, it's possible to write against the signature with no knowledge of the body or comments.

You're also forgetting that signature includes the name of the function.

reverse :: [a] -> [a] is easy to understand by it's name and type.

<comment><USER8> I didn't critisize Haskell. I only criticized a statement about its type system.

> You're also forgetting that signature includes the name of the function.

That's what I wanted to point out. The name of a function is even more important than its types. Types alone seldomly give you the complete picture of what's going on in a function.

Of course the name can be wrong whereas types can't, but the name is less likely to be wrong than a comment.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER4> The languages that tend to become popular are simply languages that appeal to the lowest common denominator. Java was the language invented for the "common programmer", and people find that comforting. Now it's Go; as Rob Pike once said of it, "They're not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt."

That's why it's always a battle to push languages like Lisp, that offer mathematical elegance over languages that are a soup of half baked idea that veer programmers away from ideas that take more than a few days to master. For those of us who aspire to do better, we should continue to try to bring the from first principles approach of functional programming to the mainstream.

<comment><USER9> Not gonna lie, to me that's a lot of words to just say "people who use popular languages are beneath me because they simply can't understand the 'beauty' that mathematical-esque and functional functional languages offer".

</comment></comment><comment><USER10> The issues mentioned are largely addressed by jshell and lambdas.

Regardless, his issues mostly boil down to "Java is not a REPL-first and Lambda-first language". This is like me "hating" my cat because it's not a dog.

I find many beginner programmers like REPL langs. When I talk to them, though, it becomes apparent that they've never worked on a code base with 100k+ lines with tens of colleagues.

One guy actually suggested that systems should never be that big! What do you say to that? I just smiled.

<comment><USER11> I think many Haskell, OCaml and Scala programmers would disagree heavily with you.

Repl driven development works _very_ well with pure functional code and at no point did I feel an increase in loc begin to make it tedious or whatever.

The repl approach perhaps doesn't work as well in Java because Java and its ecosystem encourage writing messy jumbled code built upon unsafe abstractions.

</comment></comment><comment><USER12> I've recently come around on Java (although I'll still rarely choose it), mostly due to the idea that "all things get complicated, so what matters is how you manage that complexity".

Java started to "click" when I realized how much you build objects out of other objects like layers of an onion, just adding a bit at each step, and it clicked a bunch more as I understood Spring's bean system, which itself clicked more when I began to understand that the object-based dependency graph is basically the equivalent of the top-level Ruby script. All the code describes how X and Y relate to eachother, and then you go to the bean definitions to find out what X and Y are. That's actually pretty neat.

I still prefer the "simple script" approach you can do in Ruby; and I'm loving the way Scala is kind of Ruby, but in Java, and so (and to relate to the actual content) inherits a lot more from Lisp.

So, PS, author, if you're reading this, seriously give Scala a try. It's been pretty fantastic so far for me!

<comment><USER13> Java has been gradually eating all the good parts of Scala. So far, it's eaten lambdas, map / reduce / fold functions, option types, raw string literals, the concept of a built-in REPL, type inference for local variables, and default methods in interfaces (which is kind of like mixins). Pattern matching and type classes are on the menu, but not yet formally merged into Java.

So what does Scala have left? Operator overloading, which tends to lead to unclear code. "Implicit," which should give any former C++ programmer PTSD flashbacks. A compiler which is pretty slow. The ability to embed XML into code (why?). A collections library which is nightmarishly complex. (See [https://yz.mit.edu/wp/true-scala-complexity/](https://yz.mit.edu/wp/true- scala-complexity/) )

<comment><USER14> > So what does Scala have left?

This is why I think long term Groovy is better positioned than Scala, even if short term Scala has more of the mindshare. Groovy actually offers something fundamentally different, while Scala is perpetually trying to compete on Java's home turf. If people really want a pure, statically typed language Kotlin is pretty good and has less impedance mismatch with Java.

<comment><USER15> What fundamentally different does Groovy offer?

What do you mean by "Scala is trying to compete on Java's home turf"?

<comment><USER14> Groovy is a truly dynamic language (with all the pros and cons that come with that). So you can put it into contexts such as interactive scripting where Java will always be suboptimal and solve problems Java doesn't even want to solve. On the other hand, every single good idea that Scala comes up with will eventually be co-opted by Java, because there is no reason for that not to happen. It is just a matter of time.

<comment><USER15> When higher kinded types come to Java, please ring me up!

<comment><USER14> Touche - yes, I agree that Java is probably never going to attempt to introduce that!

</comment></comment></comment></comment></comment></comment></comment><comment><USER16> It's ironic that the author claims that Common Lisp is easier to learn than Java. One of the most common pro-Lisp, anti-Java arguments I hear is that Java is too easy to learn, so that a lot of people who aren't actually very good at programming can get Java jobs. This means that the Java world is populated with not-so-bright people, while the rarefied Lisp world is full of elite wizards.

<comment><USER4> Java doesn't contain conceptually difficult features. In Rust you have to learn lifetimes and borrow checking, in Haskell Monads... Java just has a huge amount of relatively simple features. Lisp is middle of the road conceptually, but is a small language.

So in that sense I agree with you. Java is favored by people who struggle to learn harder concepts. That's why it's the usual target of the lowest common denominator programmer and loved by large enterprises that can churn Java programmers like mackerel.

</comment></comment><comment><USER17> _Beside the REPL, another impressive feat of Common Lisp is meta-programming. You can write software to write software. Say what? Yeah, that was my initial reaction too, but Common Lisp's macro system allows you to write functions that return code snippets. It completely redefines the word. Or more accurately, re-redefines, since Lisp is much older than MS Office, which is what most people associate macros with, sadly._

The article could be improved by including an example. Pick one in which Java makes the problem to be solved tedious, verbose, repetitive, or error-prone and where Lisp macros do not. Bias the example as much as possible to a problem where Lisp can shine. It should, however, be a real problem most programmers are likely to face in some form.

Then present the source for both solutions.

This approach would even help those who don't use Java regularly because they could try to implement the same functionality in their language of choice and compare it the the Lisp implementation.

<comment><USER18> Here is something from Clojure that stuck with me as particularly elegant:

The -> macro.

      (-> {}
          (add-person 'servbot)
          add-age
          add-info
          add-to-db
          notify-status-by-email
          log-user-addition
      )

So the threading operator is exactly what you ask. It inserts the results of the previous expression as the first argument as the first argument as the next expression. Note this still supports situations where an expression can take more than one argument.

Additionally, there is the ->> operator which inserts the previous result as the last argument in the next expression and some a library that includes the "magic wand" operator "-<>" ala

      (-<> {}
          (add-person 'servbot)
          (add-age 21 <>)
          (add-info 'servbot <> 21)
          (add-to-db 'my-db-handle 5432 <>)
          notify-status-by-email
          (log-user-addition 'dev 'email <> 'paint-by-numbers)
      )

This particular set of macros seems entirely trivial until you use it, and then it changes your entire perspective of what functions do since your ability to express the computation pipeline changes completely.

Edit: Update for formatting.

<comment><USER19> The Clojure standard library has had the the 'as->' macro for a while which serves the same purpose as the "magic wand". It doesn't need to use '<>' as the identifier, but I usually choose to do so because I learned about the magic wand library before I learned about the 'as->' macro.

      (as-> {} <>
          ...
          (add-age 21 <>)
          ...)

</comment></comment></comment><comment><USER20> If you are running JDK 9 or later, you can use jshell:

jshell> "Hello World!"

$1 ==> "Hello World!"

[https://openjdk.java.net/jeps/222](https://openjdk.java.net/jeps/222)

<comment><USER21> And lambdas were introduced in 8 making nearly all of the author's issues mute.

<comment><USER22> What about closures? Also, those lambdas are actually classes that try very hard to look like lambdas, but aren't actually.

<comment><USER23> What do you mean "aren't actually" ? Anything that behaves according to the rules of a lambda is one — they can certainly be implemented with classes.

<comment><USER22> There are quite a few complications of Java lambdas and their abstraction bleeds out in several edge cases. This is a result of their class implementation and would not exist if functions had first class support in the language and barcode bytecode (there are complications there too because they didn't want to change anything at the bytecode level for lambdas).

[https://dzone.com/articles/java-8-lambas-limitations- closure...](https://dzone.com/articles/java-8-lambas-limitations-closures)

<comment><USER24> Lambdas in Java aren't really that complicated. If you understand anonymous classes, you understand lambdas.

That article just compares Java's closures with Javascript's closures. The "limitation" is that Java's closures can only access the final variables of the enclosing scope. But the article agrees that this limitation "can be considered negligible" (seriously, read it-- that's the conclusion.)

Also, starting in Java 8, you don't have to explicitly declare things "final" to use them in anonymous classes or lambdas. They just have to be effectively final, meaning they are not mutated.

<comment><USER25> > _But the article agrees that this limitation "can be considered negligible" > (seriously, read it-- that's the conclusion.)_

Working both in Java and Lisp professionally, it sure as hell isn't negligible. It changes the way you write code. Lambdas in Java are 80% solution. Java 8 really did make this language finally bearable, sometimes pleasant to work with. 80% solutions are good, but the remaining 20% is not "negligible".

</comment></comment></comment></comment></comment></comment></comment><comment><USER26> A turing complete macro system is seen as a positive thing but if someone dares to mention Java's annotation based code generation and DI everyone is complaining about "too much magic"

</comment><comment><USER27> Discussed at the time: [https://news.ycombinator.com/item?id=3525927](https://news.ycombinator.com/item?id=3525927)

</comment><comment><USER28> Nit-picking a specific claim made in the article, but I honestly don't believe Lisp would be any less confusing to new programmers than Java. In fact, I think it would probably just confuse them more.

</comment><comment><USER29> FTA :

>>> But for a skeptic like myself — who spent 4 months intensively practicing Tai-Chi in Beijing, just to confirm the existence of "qi"

Has anybody here experienced this chi thing. My tai chi teacher can surely demonstrate it but I have hard times understanding with my occidental way of looking at physics... My understanding it's more a state of mind that allows the body to move in a very specific way.

</comment><comment><USER30> One big thing I notice about Java (and it's ancestor, C) is that it's designed to make it easy to pinpoint exactly what went wrong, when something goes wrong. Lisp, on the other hand, is designed so that you can get it right the first time.

</comment><comment><USER31> My biggest gripe with Java is it's insane backslash-enhanced regular expressions. No other language seems to require this ridiculous butchering of what brought me into programming.

<comment><USER24> Java 12 is going to add raw string literals which will fix this problem. [https://openjdk.java.net/jeps/326](https://openjdk.java.net/jeps/326)

</comment></comment><comment><USER32> I tried reading the _Java Language Specification_ once, but it was such insane garbage I stopped and never give it another look.

<comment><USER2> I read parts of the JLS and I found the text quite down to earth compared to the respective specifications of C, C++, and ECMAScript (JavaScript). Oh and as for scripting languages like PHP, Python, and Ruby? They don't have a standard because the implementation is the spec!

<comment><USER33> Wrong. Ruby has (one) ISO standard:

[https://news.ycombinator.com/item?id=3868970](https://news.ycombinator.com/item?id=3868970) [https://www.iso.org/standard/59579.html](https://www.iso.org/standard/59579.html)

</comment></comment></comment><comment><USER34> An old lisper would have used '(Hello World) over "Hello World". We are dealing with symbols mostly, not strings.

</comment><comment><USER35> Why are we still discussing it?

JAVA is used in most companies in the world. Lisp on the other hand - is not advised to be used in production.

To me it looks like long lost battle

</comment><comment><USER36> Lisp is the best language in the world. ^^</comment>


Microspaces (aka Nested GUIs) - <AUTHOR>

We're just about ready to release several products using our new technology.  Essentially it's a new category called 'nested GUIs' (aka Microspaces).. With microspaces you can keep info in multiple GUIs and are able to nest them in each other.<p>I'd really like to get any feedback and signups for our private beta.  Please take a look at www.nestedguis.com .. (especially the videos tab) and offer any comments.   Thanks <comment><USER2> It's hard to tell whether it'll be useable or not. Have you applied it to your codebase?

<comment><AUTHOR> It takes a few minutes to get used to... You still can click to open any portion in a new window so you're not relying on hovering.

I don't understand the codebase question?

Also, The UI is evolving.so please join the private beta. We really want feedback.</comment></comment>


Amazon could finally land in Singapore this week - <AUTHOR> https://www.techinasia.com/amazon-finally-lands-singapore <comment><USER2> It will be very interesting to see how Amazon performs versus the Asian giants. Amazon is an specialist defeating local champions in smaller markets (European countries), but Asia is a different story.</comment>


Tesla fights back against owners hacking their cars to unlock performance boost - <AUTHOR> https://electrek.co/2020/08/22/tesla-fights-back-against-owners-hacking-unlock-performance-boost/ <comment><USER2> Modding cars has been a thing since time immaterial. Tesla is fighting against a long tradition I enjoy, and I hope they lose.

I don't want every piece of tech in my life to become "look but don't touch". There needs to be a right to repair and tinker with the things you own. We're slowly becoming serfs to our own possessions and the giant tech monopolies that control them from afar

<comment><USER3> I understand and respect that point of view, if you buy something it os your property and whatnot, but the counter point to that is that Tesla when not running still pack +70kWh on 400v busbars so this isn't your typical iPhone repair either.

Yesterday I saw a video of a few people in a garage from what I assume is a garage in the US, salvaging the cells in a Tesla battery pack and not one of them had decent protective gear.

Again I don't disagree with you, but I understand why it might bea serious liability for Tesla.

<comment><USER4> I've seen videos of teenagers being careless with angle grinders but you don't see homedepot freaking out.

Label things and _write decent manuals_ don't write broken software with safety as an excuse.

</comment></comment></comment><comment><USER5> Those that impose software barriers to utilization of purchased hardware are doomed to people doing what people who paid good money for something do.

Yet still these business models propagate. Something about the definition of insanity being doing the same thing and expecting a different result.

<comment><USER6> Brings to mind the ongoing battle between John Deere and the Ukrainian hackers. I haven't kept up with the fight but if I were a gambler, I'd put my money on the Ukrainians. Non-tech companies tend to write dreadfully poor software. Can't imagine their software locks are any better.

</comment></comment><comment><USER7> Couldn't they decide on a mechanism that does not have the code in there by default, and then electronically deliver it as a module when a customer pays for it?

Maybe the problem is harder than that, but I doubt there is no solution. It's not a new problem, as we've seen with John Deere already.</comment>


From Ruby to Haskell, Part 1: Testing - <AUTHOR> http://bendyworks.com/geekville/articles/2012/12/from-ruby-to-haskell-part-1-testing

<comment><USER2> Just talking aloud, here. Sorta frustrated.

I recently dove into Scala for fun and I enjoy its terse syntax (often more terse than Ruby's!) and principles. I was really excited about it at first.

But the excitement went away pretty quickly last weekend when I actually tried building things with it.

Setting up a Sinatra app in Ruby is a matter of 'gem install sinatra', a 'require "sinatra"', and you're ready to roll.

Meanwhile setting up a Scalatra app in Scala was a far more involved process, every tutorial getting me to use a tool called 'giter8' just to copy down app boilerplate from github. I also ran into general difficulties just setting up IntelliJ/Eclipse, falling back to Vim which makes compilation errors feel like runtime errors since I had to go back to the terminal to see that my program didn't even compile.

I pine for a world where I can just `scale install scalatra` (or pop it into my Scalefile), `$ vim app.scala`, and begin coding.

I still plan on writing some "Scala for Rubyists"-type blog posts, but it's a shame I couldn't figure out and enjoy the actual workflow. I'd have more patience coming from an ecosystem that didn't make things as easy as Ruby's does, but I've realized that tools/workflow/environment are showstoppers no matter how much you enjoy a language.

<comment><USER3> You are not alone in this. Scala has had ecosystem problems for a long time and because of the community status, that's unlikely to get much better anytime soon.

One of the reasons I've been preferring haskell and clojure for my work is because scala's toolchain abused me so badly.

<comment><USER4> As I've just scratched Scala's surface, I don't get what you meant by the community status. Considering how important the ecosystem is, could you point some resource to understand ? Thanks

</comment></comment></comment><comment><USER5> Heh, never seen someone so defensive about using Haskell before.

I'm not sure that the "here's now to do this Ruby thing in Haskell" method of learning Haskell is a good way to go about it. It would work well to teach Python or JS but not a Lisp or Haskell or Prolog. They differ at a lower level and require different mental models to even understand them, nevermind thinking in them.

I don't see it helping if you are trying to cram monads, laziness, side effect free programming, inferred types _and_ new syntax into the mental model of code execution you use for Ruby.

Has anyone learned that way and found it useful? Do you learn a few things in a familiar context while cargo-culting the rest and then fill in the gaps later? Does it just click all of a sudden?

My biggest struggle was learning to think in Haskell and this type of mixed metaphor teaching material would just make things worse. That might not apply to everyone, but if it applies to you then you aren't alone. Try learning the execution model with little toy programs first, then move on to the kind of software you are used to writing once you know how to look at Haskell code and reason about what it does.

<comment><USER6> "Has anyone learned that way and found it useful? Do you learn a few things in a familiar context while cargo-culting the rest and then fill in the gaps later? Does it just click all of a sudden?"

That's how I learned to write my first useful programs.

Maybe there is a better way, but that is the direct answer to your direct question.

Except I wouldn't say that it clicks "all of a sudden". It's a long process of learning. One day something doesn't work, and you think it should, and you just keep narrowing it down and eventually come to some deeper realization. It's the top-down approach to learning.

I've been trying to learn haskell bottom-up for a while, and I've done a few things and have some understanding of the theory. But I don't have anything to show for it. Every time I learn some new theoretical thing, I think "wow, what could I program with this?", at which point I've already lost. Because once I start thinking about the language rather than the utility, I'm not likely to create anything amazing.

I think that I'd be more successful if the next idea I had I just coded up in haskell (even though I don't really know it) and pushed through to a solution by any means necessary. But for me, learning a new language is secondary to realizing my visions; and my visions rarely start from an empty file any more.

That being said, I think a mix of bottom-up and top-down is probably best. There are some fundamental things that you need to learn deeply at some point to be good. Not sure the exact stages that these things should be learned, though.

<comment><USER5> Interesting, I did bottom up first and then when I started to feel that same itch to actually build something useful things were more top down.

I agree that a mix of bottom-up and top-down is probably best, I was curious about other paths because I found that starting with bottom-up worked really well for me and wondered if that generalized to other people or was just well suited to my learning style. My experience makes me think that a solid foundation is essential but it's entirely likely that's just "that's the way i learned" bias.

</comment></comment></comment><comment><USER7>
       move from perhaps the most dynamic language to what is perhaps the most static?

I don't think this continuum has any meaning, but s/he should look at GHC Typeables, deferred type checking and the type holes work in the "most static"

[http://www.reddit.com/r/haskell/comments/10u7xr/ghc_head_now...](http://www.reddit.com/r/haskell/comments/10u7xr/ghc_head_now_features_agdalike_holes/)

<https://news.ycombinator.com/item?id=4380900>

[http://hackage.haskell.org/trac/ghc/wiki/DeferErrorsToRuntim...](http://hackage.haskell.org/trac/ghc/wiki/DeferErrorsToRuntime)

<comment><USER7> Here's where the "most dynamic/static/whatever" probably came from

<http://james-iry.blogspot.com/2010/05/types-la-chart.html>

</comment></comment><comment><USER8> Why? whats the need or advantage of going to Huskel from Ruby??

<comment><USER2>
        > If you read it as "stop using Ruby and start
        > using Haskell", you read it wrong.

He also goes into why he likes some of the things Haskell brings to the table in the remainder of the article.</comment></comment>


Ask HN: Linux from Scratch.. Should I try it? - <AUTHOR> For a long time now, I've been pondering over whether I should dive into Linux from Scratch (http://www.linuxfromscratch.org).
I've been a Linux user (Ubuntu) for over three years now, and the stuff I've learned is only by trying/troubleshooting and so on.. I've never really read a book about UNIX (even though we had the course in college).
So, have any of you HNers tried out the LFS project from start to finish? Is it something that'll teach me more about how the Linux operating system works (of which I have a pretty decent idea), or is it something that help me towards my goal of becoming a Linux power user ?
Any opinions or help would be awesome! <comment><USER2> Let me take the flak: No.

Why? Well - unless you have a very specific reason [1] it seems to me that LFS is too much time invested for not enough return. As others commented, you can go a long way with a source based distribution. Learning a different distribution's way to do things might already be pretty interesting (and arguably more useful: You'll probably never hit a LFS system in real use that needs fixing, but you might stumble upon a solaris/freebsd machine or even just a heap of Suse/RedHat/Debian/Slackware machines) and challenging. Start with that!

LFS is a purely academic thing for me. You follow the guide, just to end up with a system that is really nothing for daily use (or - needs too much work).

All the above assumes that your definition of a linux poweruser is someone that understands the darkest secrets of the OS. Which - is not exactly necessary. I know plenty of users that I'd consider power users because they focus on things they actually need (and improve those, get better at those), not things that somehow make this possible.

Cue the car analogy: A race driver would be a power user for me, I don't require that he can build a race car from scratch..

[1]: Some reasons I could imagine to change the answer to a yes:

1) You want to really build your own distribution for an embedded device and don't like openembedded

2) You are (or plan to) a system administrator and want to learn more underlying details for your job.

3) You plan to get into system-level programming/contribution and want to understand the status quo first.

<comment><USER3> I'll mostly agree.

If you foresee building any custom embedded Linux systems, even if you like openembedded, it gives you a good picture of what's going on down there (and a good picture of what openembedded is doing for you).

If you want to learn system administration, I really don't see it being that helpful. You'll learn what all the components of the system _are_ and how to build them, but not necessarily how to use them.

I'd suggest that if you're a hacker type, you might want to try it anyway, just for fun. :-) But in general the knowledge you get from building LFS or Gentoo or similar isn't actually that useful from a system administrator/power user perspective.

I'll also second the comments from other people who built it, and then abandoned it: LFS is too finicky to manage and too hard to upgrade for me to do any real work with it. For me, it's a toy system that I play around with, then reboot into Debian/Ubuntu/Fedora/whatever to go get real work done.

</comment></comment><comment><USER4> You could try using something like Gentoo first. You'll get to learn a lot, just by trying to set it up on your system. And even then if you feel you need to dig deeper, you could try LFS.

LFS is something which people can use to create their own distros (I think I read somewhere that ArchLinux was created using LFS), which reminds me you could even give ArchLinux a shot. Pretty nice distro. ;-)

<comment><USER5> Yeah, Gentoo and Arch are both good (or were when I last tried them, several years back).

Daniel Robbins is also working on new Gentoo kernels and portage trees (and has a _ton_ of Linux documentation/tutorials) over at <http://funtoo.org>

<comment><USER6> _several years back_

I used Gentoo back when they still had regular release numbers instead of dates (1.2 I think) and stage 1 installs. Back then the docs were complete and extremely comprehensive and the Gentoo Forums were amazingly resourceful. The distro and the community have slowly degraded in quality since drobbins left. (This is not necessarily related to his departure.)

Anyways, it was great for learning. Before that I tried Red Hat and was confused as hell. I couldn't troubleshoot anything. With Gentoo I constantly broke things but was able to find out how to fix them relatively easily. I quickly built up an understanding of how everything fit together.

Maybe Gentoo is still useful in this regard but it certainly is not what it used to be.

</comment></comment></comment><comment><USER7> 1) Why exactly do you want to be a "Linux power user"? That doesn't sound like a real goal; you might want to elaborate.

2) Why exactly have you been pondering over it for so long? The cost of trying is next to zero. At worst, you'll end up with an unusable test machine, give up, and try something else. Simply going ahead and trying is probably better use of your time and energy than pondering for a long time and looking for advice as to whether you should try.

<comment><AUTHOR> 1) Mostly because I want to exploit everything that Linux offers - and I wish to move out of Gnome on Ubuntu.

2) It's mainly because I'm halfway through the alpha-launch of my web-startup, and have a little time to spare, which I want to use productively. I haven't been 'actively wasting time pondering over it' , it's more like 'been at the back of my mind' sort of a thing.

//edited: making my point more clear.

<comment><USER8> I used Archlinux a while back. That was back when i was still a Unix toddler (not that I've matured very well since then). I actually had fun with it.

Try living out of a TTY for about a month. You will come out with rustic beard, red eyes and a triumphant smile. No Gnome or gdm, screen to take care of your "windows", mpd (ncmpc) to play your music, elinks to browse the web, surfraw to search, vi to edit your files, irssi for irc, bitlbee for msn etc. Control your daemons with rc.conf and begin your journey :)

<comment><USER9> I second that. For more terminal apps, check out kmandla's blog: <http://kmandla.wordpress.com/software/>

<comment><AUTHOR> Wow, that's exhaustive! Can't wait to try out the terminal apps there. I really want to live in a TTY for some time now.

</comment></comment></comment></comment></comment><comment><USER10> I used LFS years back when it first came out. I found it extremely useful in terms of learning a large amount of how Linux works under the hood. If you goal is a weekend or evenings project that will help you understand how libraries work, how startup scripts work and how to customise things then LFS may be for you. If on the other hand you want a systems usable for day to day tasks, avoid it like the plague.

If you're thinking of a Linux power user as someone who lives closer to the bare metal, I'd highly recommend Arch (<http://www.archlinux.org/>). Some people recommend Gentoo, I personally prefer Arch. Arch is like LFS without (all of) the pain, plus you get package management.

<comment><AUTHOR> I did not know about Arch. Thanks for the recommendation, I've bookmarked it and will be sure to check it out..

</comment></comment><comment><USER11> I used LFS exclusively between about 2001 and 2003. My motivation then was mostly the fact that every distro sucked so badly. That's no longer the case, but I definitely recommend it as a learning experience. Afterwards you'll no longer be intimidated by the prospect of having to track down any distro- specific bug that a package maintainer can possibly inflict on you.

<comment><USER12> > ... fact that every distro sucked so badly. That's no longer the case ...

What would you recommend?

<comment><USER11> Debian stable or Ubuntu LTS.

<comment><USER12> Thanks!

</comment></comment></comment></comment><comment><USER13> I worked through the LFS book in 2002/03. Can't say I learn't much - the book is (well, was - it might be different now) written as a HOWTO without much explanation of how and why everything works.

The basic process as I remember it was to bootstrap a system by making a new partition, setting up a minimal directory tree, building a new C compiler (& libs/associated tools) then chrooting to it and using it to build up the rest of the system.

It was a fun process but tiring and time consuming. I wouldn't do it again.

</comment><comment><USER5> I never actually did the LFS process, but I used various linuxes as a main desktop for about 4 years.

It depends what your goal is. Linux from scratch will mainly teach you (wait for it) how to build linux from scratch. Systems that are not quite "from scratch" but are lower level than Ubuntu (eg, Gentoo, Arch (others?)) will also teach you some of this. I used Gentoo for years, and after compiling about a dozen kernels in a row to get things to work how I wanted, I guess you could say I'd learned something, if only 'what kernel options I want to enable on this hardware'. :)

But building Linux won't really teach you to _use_ it. If you want to be a power user in the long run, your time (and LFS will take a _lot_ of time!) might be better spent learning your shell/package manager/scripting language of choice in greater depth, compiling your own kernels and adding them as options in grub/lifo, that sort of thing.

All that said, if the LFS process sounds really appealing to you, go for it. You'll definitely learn _something_, but just maybe not as much as you're hoping.

<comment><AUTHOR> Thanks for the elaborative answer - which definitely cleared out some things.

</comment></comment><comment><USER14> Absolutely. If you have any desire to really understand what makes up a base working linux system then going LFS is for you. It not only gives you special insight into what goes into making a full-fledged distro but also teaches you some excellent problem solving skills.

Personally, I would start with a target "result" in mind. Maybe you want to create a minimal "server" layout or "lean desktop". Once you hit that point and have documented what it took to get there, throw it away and start again. Think about how to automate some aspects of the process.

I'm actually doing this right now with my OH SO COPIOUS free time. Building a VM-only target distro that's designed to be minimal and run only in a VM. The rest is expected to be managed entirely from tools like Chef or Puppet.

It's sort of a "put up or shut up" to this blog post: <http://goo.gl/rML9>

<comment><USER15> URL = [http://lusislog.blogspot.com/2010/09/distributions-and- dynam...](http://lusislog.blogspot.com/2010/09/distributions-and-dynamic- languages.html)

<comment><USER14> Ahh sorry. I just copied and pasted it from a tweet I had sent out previously.

<comment><USER15> Not a problem. Just wanted to give people who are afraid of shorteners the full url.

</comment></comment></comment></comment><comment><USER16> If you have a lot of time on your hands, and you like experimenting - give it a go: you'll learn a lot (and more than likely, you will also lose some hair).

However, you can learn linux pretty darn well without ever building a system from scratch. You don't need to do that to become a "Power User" (though, for some, it helps).

The thing is, a system can work in many wildly different ways: just look at the system init procedure: there's file-rc, traditional sysvinit, various paralellizations, dependancy based init, systemd, and a whole bunch of other stuff.

There's also distributions which do not follow the FHS, for one reason or the other, and those work differently from the ones that do.

And so on, and so forth...

But anyway, if you have a lot of time, and you think it would be useful for you - go ahead.

Myself, I never found it neccessary to indulge in building a system from scratch.

</comment><comment><USER17> I used LFS in high school (8 years ago). It's how I learned 90% of what I now know about administering and troubleshooting Linux servers.

If that's your goal, I recommend it.

<comment><USER18> I also went through the book in school, I learnt so much from it.

Back then, I only had a single computer, so while I didn't really need your computer for day-to-day work (or at least, it was rarely required to maintain my income), it forced me to carry on with LFS long past the book, all the way up to installing GNOME and OpenOffice. It was very worthwhile, and the residual knowledge I have from that process is still used frequently.

</comment></comment><comment><USER19> I haven't done it myself, but based on talking to a few of my friends that have, most agree it's an interesting idea, but that it wasn't really worth all the time it took, as it didn't really teach them all that much more than they already knew. Granted, this comes from people that have a fairly solid Linux background and typically run distros closer to LFS than Ubuntu (think Gentoo and the like), so depending on your back ground, your mileage may vary.

Personally, I'm still interested in taking some time to do it, and I've actually been trying to convince some friends of mine to spend a weekend, with each of getting a system hacked together. There appears to be lots of interest, but getting everyone to agree on a time might just be impossible. Perhaps I'll dig that project out of the closet this weekend and get it done myself...

In any case, if you're looking to understand Linux better, it will probably help, but I would suggest that there are probably better avenues for learning it. Advanced Programming in the Unix Environment will teach you all the subsystems you have to interact with (albeit, typically from a programming view), and Understanding the Linux Kernel will teach you the ins and outs of the kernel like nothing else. There may be better books out there for what you're looking for, but those two I have direct experience and would highly recommend.

On the other hand, if this is something you're interested in doing, shouldn't that be reason enough? You'll likely learn something on the journey, though it may not necessarily be Linux-related, and you'll be doing something you want to be doing.

</comment><comment><USER20> I have implemented LFS once, so I'll be happy to give you my impressions:

1) The LFS manual will get you to a _base_ Linux system. Think of it as the minimal system required to get you up and running and nothing more. You will need to use BLFS or something else to get yourself to point where you will most likely be comfortable (especially as an Ubuntu user).

2) There is no package management by default. The manual recommends some ways to handle this including rebuilding the entire system from scratch (!) when you want to upgrade. So, after all of the work you do (which is mostly watching things compile) you are still responsible for maintaining all of your installed applications. For the average Linux system, this is _a lot_ of packages.

3) All of that said, it is an interesting process to go through if you would like a little more insight into how a Linux system works, assuming that you take the time to understand what you are doing (and why) and not just blindly follow the manual.

Shortly after completing the project (completed over a weekend), I found that I had learned a lot but had no desire to maintain the system. I believe (don't quote me on this) that the creator of Arch Linux started from LFS.

In the end, I use Linux Mint. It's like Ubuntu with a better organized interface (IMHO) and more attention to visual detail.

Should you try LFS? Sure, why not? It won't kill you and maybe it will spur some new project or idea in you. Worst case scenario, you spend a few hours rebuilding a machine.

Hope this helps.

<comment><AUTHOR> Thanks for sharing your experiences on LFS. It cleared out a lot of misconceptions I had about it, and I'll be sure to check out Arch

</comment></comment><comment><USER21> If all you have used so far is Ubuntu, then what you have learned is "how Ubuntu works", not necessarily how a Linux system in general works.

As another commenter pointed out, given the zero cost (other than your time) nature of trying something out, why ponder? If your pondering is that you don't want to mess up your current system, then install Virtual Box and run whatever else you want to learn from in a virtual machine inside VB.

The problem you may encounter, given that you say you've been only using Ubuntu, is that LFS may be taking a dive from the high platform into the deep end of the pool when you are not ready yet for that experience. You may want to ease into that just a little bit more.

My suggestion for you is to go download yourself a copy of the latest Slackware distribution, and start there. You'll learn 95% of what LFS will teach you just from Slackware alone, without also taking that high dive before you are ready.

And, again, if you don't want to kill your current system, then just install Virtual Box and then install as many distro's as you please (including LFS) as VM's. You get the same experience, without breaking your current working system.

</comment><comment><USER22> In order to learn Linux (or most things) an excellent way besides tinkering randomly is to set specific goals.

When I was a kid I was taking a sailing course when my uncle (a seasoned sailor) asked me what we've been doing. I told him we've been just sailing around as we pleased and he said that was pretty bad, like learning how to drive by driving in an empty parking lot. He said we should try to get to this buoy first, then to this one etc.

I suggest (unless you are very interested in desktops) you get a Linux server in the cloud (rackspace is $12/mo), this will get you connectivity, it will force you to use the command line and you can always re-install it with a click if you mess up.

Make a list of objectives. If you need some suggestions:

\- create a mail server, add users, manage forwarders, aliases, spam, why your messages don't reach hotmail etc.

\- play with the firewall, how to deal with a bit of DoS, what about those pesky ssh brute-force scans?

\- install a honeypot

\- create DNS server

\- install monitoring tools

\- get some web app (wordpress, drupal for example), benchmark/stress test the heck out of them, try changing caching and other things, how to optimize apache etc

\- write some shell scripts to automate/check some of the things you've done

etc

</comment><comment><USER23> I built a linux from scratch a long time ago (before that page existed). You'll learn a lot about how a linux distribution is put together, but that isn't in itself particularly useful.

Such knowledge seems most useful if you're working on some hardware device with linux embedded -- where it will be interesting to know about all the parts you can leave off or replace with smaller alternatives.

</comment><comment><USER24> I built a LFS system about 5 years ago. At least back then, the book felt a bit incomplete. While it told all the steps needed to build a system, it didn't really explain _why_. Download this specific version of a package, download this magic patch, and type in ./configure, make, make install. What it failed to tell is where to find those patches, how to find compatible versions of software, what alternatives do some software have etc etc.

Based on that experience I wouldn't recommend LFS. Either spend your time studying some prebuilt system (I remember one time installing Debian via chroot, which came out extremely minimal, and that was somewhat interesting), or actually design and build your _own_ Linux-based system. Outline (maybe on paper) what parts you want (maybe you have heard of some trendy init replacement, or you just hate pulseaudio and love oss, etc). Then research what you need to run that stuff. It will take a lot more time, but it will also be much more rewarding

</comment><comment><USER25> I've re-read your question three times and can't find what you're asking... what do you want to get out of it?

<comment><AUTHOR> Sorry if I wasn't clear enough. I just want to move out of using gnome for Ubuntu and become a 'power user' ( for the lack of a better term, but I hope you get the point - someone who knows the UNIX system inside out - and is able enough to help people troubleshoot, and so on. I hope my definition of 'power user' was good enough. If I'm wrong, then I'm sorry and please feel free to correct me.

<comment><USER26> Are you comfortable using the command line and nothing else? There is a lot you can learn by being able to configure, diagnose and fix systems using only the core tools. Once you have that under control, you might want to compile and install specific device drivers. Oh, BTW, I recommend using an old, spare PC. Maybe try TinyCore or DamnSmall Linux rather than something as complete as Ubuntu.

</comment></comment></comment><comment><USER27> Quite recommended if you want to learn more about how a Unix system, and Linux in particular, is put together.

I installed it a long time ago, and I remember learning a ton. I suggest that you dig deeper into any topics you read about in the manual that you haven't heard before. I remember lovely all-nighters learning about dynamic loaders, binutils, object files, ELF and ld and so on :)

When I used to recompile the kernel I also learned a lot by trying to figure on my own whether some options should be enabled or not. This resulted in several unbootable kernels, but I also learned what was IPC, NUMA, the IO-APIC and other stuff that wouldn't come my way otherwise.

The downside is a lot of time spent waiting for stuff to compile before you can move on, so make sure you have complementary material for those times.

</comment><comment><USER28> If your goal is improving your UNIX knowledge: it may help, or it may not. Back in the days when LFS was new, I saw lots of people trying it, but who didn't learn much along the way since they would just literally paste the commands from the LFS book. If you use it like that, it is just a way to waste your time, and leave you with an unmanageable Linux system.

What may be more interesting is to try one of the minimalistic BSDs (NetBSD or OpenBSD). You will likely learn far more, e.g. that many GNU-isms that you may have gotten accustomed to are not UNIX-isms. You'll be able to build your own customized NetBSD systems using the excellent build infrastructure. You can play with some of the nice packet filters (ipf/pf). Or spend time fixing pkgsrc ports that fail ;).

<comment><USER29> I'd agree with using OpenBSD as a learning tool (although it obviously makes a top notch deployment platform as well).

Once you get your head around it you'll realise that Linux is a complete mess and you'll understand more about UNIX and UN*X.

<comment><USER30> Somewhat more objectively - the man pages on OpenBSD are _superb_ , and having a clear yet exhaustive reference will make it much easier to figure out how things work. FreeBSD's documentation is also good, particularly the handbook, and the slightly larger community translates to more information on forums. (That said, I also prefer OpenBSD.)

</comment></comment></comment><comment><USER31> For most people it's a huge waste of time. How many hours do you think you'll spend on this? Do you have anything else you'd rather spend these hours on? For example guitar lessons?

If you want to become a system administrator go for it. Otherwise probably no.

<comment><USER32> I second the "only for system administrators" advice. There are a million and one things to know about Linux. You don't need to know everything; you need to know how to know the things you need to know. You won't learn that through undirected comprehensive tinkering.

</comment></comment><comment><USER33> Well, if your aim is to understand the basics of OS by engaging with its code then you can try "Pintos". It was designed to introduce undergraduates to concepts in operating system design and implementation by requiring them to implement significant portions of a real operating system, including thread and memory management and file system access. 1\. <http://en.wikipedia.org/wiki/Pintos> 2\. [http://www.stanford.edu/class/cs140/projects/pintos/pintos_1...](http://www.stanford.edu/class/cs140/projects/pintos/pintos_1.html)

</comment><comment><USER34> If you've only ever used Ubuntu and for only three years, then chances are you actually don't have a "pretty good idea" of how linux works. I don't mean that in any disrespectful way... but READ some books on unix.

You shouldn't need to ask - you should just go try it out and form your own opinions. Use any type of linux/unix you can get your hands on and learn and form your own opinions, and read.

If you've only ever used ubuntu, then using ANY other unix or other distribution is going to teach you something - just go for it.

</comment><comment><USER35> I have compiled a LFS distribution four times, it's good to see how the system is built, you'll learn parts of the system that are very important but not much people understand how they work (PAM for example), there are more things to learn as well (metrics of the system) and some other stuff that will not learn in LFS.

</comment><comment><USER36> I learned about linux back in 1996 and tried LFS in about 2000. It helped me immensely in understanding what I'd been playing around with.

</comment><comment><USER37> Do think it is fun? Then do it. If not? Don't do it.

</comment><comment><USER38> More knowledge cannot hurt you, only help.

Go for it!

</comment><comment><USER39> I gave it a go back in 2000 .. I've never learnt so much so quickly and had loads of fun and hair pulling moments. One tip, when you get your system up and running to "init 3", modprobe your soundcard driver and spin up "Orbital - Halcyon" .. If you're a fan of the Hackers film that is ;)

I never done anything else with my build at the time, but I did join the Arch Linux community which is a distro based on LFS with a package manager. So I effectively went from knowing very little about Linux to being a package maintainer for a distro over the course of a weekend.

</comment><comment><USER40> I am in almost same position as you. Looking for expert advice.</comment>


The Trouble with "Dream Jobs" - <AUTHOR> https://medium.com/@philipkd/how-i-found-work-that-i-love-a5db97df69f4

<comment><USER2> It's easy to feel like you've figured it out, the question is whether your feeling turns out to be true.</comment>


Recursion best practices - Carpe diem (Felix's blog) - <AUTHOR> http://www.idryman.org/blog/2012/04/14/recursion-best-practices/ There are not much design patterns on functional programming. I hope these guidelines can be a start <comment><USER2> A better style for the (Haskell) "return a list of fibonacci numbers" example would be

      better_fibs 0 f1 f2 = []
      better_fibs n f1 f2 = f1 : better_fibs (n-1) f2 (f1+f2)

as this generates the list lazily.</comment>


Show HN: Whistle-based Authentication - <AUTHOR> http://popdevelop.com/whistle With the rise of more and more clever authentication methods, e.g. fingerprint (Apple Touch ID), facial recognition (http://mashable.com/2013/07/25/facial-recognition-payment) and clicking in pictures (http://pixelpin.co.uk), we thought that why not take this trend to the next level:
Whistle-based Authentication: http://popdevelop.com/whistle
The project uses HTML5 audio (in Chrome) together with some basic signal processing to detect notes that are whistled in a certain order. Only the order is important, so no need for perfect pitch.
And kids, don't use this in anything close to a production environment. This project was developed during the Malmoe Music Hack Weekend 2013 and only supports the two demo users. However feel free to fork the project and add your own users and melodies. <comment><AUTHOR> With the rise of more and more clever authentication methods, e.g. fingerprint (Apple Touch ID), facial recognition ([http://mashable.com/2013/07/25/facial- recognition-payment](http://mashable.com/2013/07/25/facial-recognition- payment)) and clicking in pictures ([http://pixelpin.co.uk](http://pixelpin.co.uk)), we thought that why not take this trend to the next level:

Whistle-based Authentication: [http://popdevelop.com/whistle](http://popdevelop.com/whistle)

The project uses HTML5 audio (in Chrome) together with some basic signal processing to detect notes that are whistled in a certain order. Only the order is important, so no need for perfect pitch.

And kids, don't use this in anything close to a production environment. This project was developed during the Malmoe Music Hack Weekend 2013 and supports only the two demo users. However feel free to fork the project and add your own users and melodies.</comment>