skysight-inc/HackerNews huggingface dataset:
I'm pretty sure it's your reading comprehension that's at fault here. Don't blame the article for you making a mess of it.

> Page 2 seems to imply that part of Lanier's dislike of digital culture stems from the fact that MIDIs can't represent saxophone music.

from the article:

Indeed, one of the foundations of Lanier’s critique of digitized culture is the very way its digital transmission at some deep level betrays the essence of what it tries to transmit. Take music.

One of the foundations is a general process, and music is used as an example for that process. Which is so far from what you turned it into, I'd really suggest reading it all again.

> Later on that same page, the article seems to imply that automatic translation is bad because "by taking value off the books, you’re actually shrinking the economy." That is, because technology allows something to be done more cheaply, it's actually hurting the economy by shrinking nominal spending.

What he actually says:

[With translation] you’re producing this result that looks magical but in the meantime, the original translators aren’t paid for their work—their work was just appropriated. So by taking value off the books, you’re actually shrinking the economy.

The way I understand that: If you don't pay the people who do the work, and people who make a collage out of their work get paid, you'll end up with much fewer new translations being undertaken. You take money from the people who do the work and give it to those who made a collage from it, and the total amount is much less. His argument isn't "it's bad because it's cheaper" -- rather your counterargument seems to be "that [criticism I kinda missed] is made up for because it's cheaper".

And I disagree. If I can buy a bun for 20 cents, or someone could rob the baker and give it to me for 5 cents, I'd rather have the bun for 20 cents, because that means more delicious bun tomorrow, and the day after that.

> Isn't every other non-tech article on HN a critical piece?

Critical, yeah. Self-critical (big difference) in the sense of "why I didn't succeed or how I could succeed harder", yeah. But in the sense of "wtf am I doing, why, and should I really be doing it?" -- not so much. You say every second non-technical article? Can you link me ten from the last 7 days? Not because I don't believe you, but because I want to read them, and at the very least I want to know what kind of article you think qualifies for this. Also, if the consensus here is that criticism is given too much attention (which doesn't even mean there's a lot going on, just that what of it is going on is already too much for some people - logic!) kinda confirms is point instead of refuting it.

But it's not about criticism anyway, it's about being self-critical. Plus, HN isn't the whole industry. So how would that even be a valid counterargument if it was true? (which also makes me asking for those self-critical articles kinda moot; I just like to be throrough)
You made a few python mistakes but that explained the basic concept much better than what dons wrote.

He once again tries to explain monads using terminology that only people who already understand them can follow.
Hacking the Kinect on a Raspberry Pi
You nailed it. Dont buy the hype
Although devise is by far the most popular, by looking at rubygems[1] it seems AuthLogic still is fairly widely used.

[1] http://rubygems.org/gems/authlogic
The lulz does not seem like a fair reward when the adversary's not even slightly squeamish about abducting you and your family and selling your organs.
My Dad was in the Canadian Coast Guard the HUET classes are mandatory.

It's a good thing because I think Dad said over half the crew couldn't even swim!

Not that it matters you'd be dead in three minutes anyway without a Mustang suit.
Webshell.io
Or we have worked places where our bug reports are taken at low priority compared to real customers'. Real customers often don't bother reporting simple bugs, either assuming they will be fixed anyway or judging their value (to one user) as too small. So fit and finish suffer, because developers who do care are systematically ignored.
They may. Or they could drop the prices just enough that importing charges would make up the difference. It's just rules of the game. If they change, adapt your business model or go bust.

But I'm not objective. For me segmenting (like DVD zones) always looked like and artificial way to milk more cash out of people.
This is my experience of him, too. I've never understood why he gets the attention he does, except perhaps that he fits a nice caricature of what people who want to be lectured at, think the lecturer looks like. Besides a branch of technology that fizzled out, he's contributed nothing of which I'm aware has had any real impact on my daily life. Being a perennial on the TED circuit is an effect, not a cause.
> It's just something that needs to be thought through.

Your statement is what I mean.
"Thinking things through" should be done during design.
Once you have built system, its much harder to compensate for design flaws.

Programming is not designing.
Designing is not programming.
Fixing bugs is not designing.

You have to design into the UI system a means for it to compensate for changes in user behavior. You don't want a system that takes many uses to train. At the same time you don't want a system that is trained by a single use.
For me this is the crux of the problem.

The happy medium that automatically detects deviations from a user's 'normal' behavior _and_ takes the correct action is very hard to design, as it involves AI fuzzy logic.
They emphasised architectural elegance over short term practicality - ie do it right rather than do it quickly. The problem with operating systems is that you need to have a minimum set of working functionality in order for it to be somewhat useful to people not developing the operating system itself. You need a way of storing data, you need a reasonable number of commands to run, you need editors etc. On the hardware side there was immense turnover in the late eighties and nineties. Processor architectures soared and waned, it wasn't uncommon for cpu speeds to double, memory become increasingly cheaper, peripherals changed (mice, cdroms, floppies changed size, Zip drives, tape drives), popular hardware buses changed (ISA 8/16 bit, ADB, VLB, PCI, PCMCIA, USB, serial, parallel). Just keeping up without changing your operating system core functionality was a lot of work!

The GNU project tended to work very cathedral like, while Linux was very bazaar like. The latter meant people could support and update the kernel for their own devices ("crowdsourcing" in today's terminology). http://www.catb.org/esr/writings/homesteading/cathedral-baza...

To give you an idea of how many shortcuts Linux took, the way the original kernel worked was that it used a single large address space. Each process was slotted into 64MB of that address space. That left you with a maximum of 63 processes. A context switch just involved changing protections to enable the appropriate slot. This is far more lightweight than how Linux now and other operating systems do it with no such process limits and a far more heavyweight full address space switch. Back then it made Linux really fast at process switching. This is an example of "worse is better": http://en.wikipedia.org/wiki/Worse_is_better

What the detractors didn't realise is that the initial simplistic Linux implementation could evolve away the constraints, and were instead betting on up front "intelligent design".
Do you have any current examples of consumer level microwaves with that simple interface? I've been looking for exactly that sort of simple microwave, but I haven't been able to find any in my brief searches on the internet or in the large mart style stores.
Chrome has essentially 3 modes in which you can display pages. Windowed, Full Screen, and Presentation. If users use windowed, they have to manually size out the window to the screen bounds. Full screen mode obviously shows the page full screen. Presentation shows it full screen without the tab and address bars. Unfortunately, both the Full Screen and Presentation modes render other displays useless with the OS X fiber weave screen.

Chrome has to be relaunched from time-to-time for updates or system restarts. Users are left up to restoring "Recently Closed" tabs and windows or sizing out the window again. Sometimes users "close all windows", "minimize all" or hide the application without thinking about the one containing the "dashboard" view in the background. These inconveniences become distracting and require users to always be careful to remember that they have that one view they never want to dismiss.

Looking Glass was designed to avoid these issues. It doesn't render your other displays useless when presenting a web view full screen. It's meant to be a set-it-and-forget-it solution. Users can still do their normal work without fear of accidentally closing their "dashboard" view. A major concern of web-baseed kiosk application is that it's easy for people to navigate away from the page because the address bar is easily accessible. In Looking Glass there isn't an address bar immediately available for users to change the desired location. In the future, I imagine Looking Glass will also include a password lock feature so the start page URL cannot be changed by anyone who is not an administrator.

These are the main v1.0 differences between Looking Glass and Chrome's page presentation modes.
> I think your (sic) arguing against abstractions in general

No.

> We replaced a manual, verbose and error-prone pattern with a standardized abstraction

Alternatively, we replaced some easy to follow procedural code with a manual, verbose, and error-prone abstraction. I have no idea what is going on with the author's decorated classes, generators, etc.

How do you create a new monad pattern and debug it? All code is imperfect; it feels like we're just shifting some of the logic around to a different place.

> since most abstractions we care about obscure control flow - whether functions, loops or monadic bind

This is apples and oranges. Functions and loops are straight-forward, monadic bind (in this framework) involves indirecting through a bunch of complicated Python magic.

> I don't write my own stack push/enter/pop to call functions, and nor should I have to write out all the other boilerplate control flow patterns I use, when it can be simply programmed into a monad, and left to the compiler.

It sounds like an arguments from the exceptions camp — "everything would be so much better if we didn't have to check error returns from every subroutine!" But like exceptions over error codes, I think introducing monads is inventing a bigger problem to solve a comparatively small problem.

Just my 2¢.
> I don't think the fundamental problem with them — performance is horrible — had been made obvious yet.

On the contrary, the idea that performance of microkernels is "horrible" is the current received wisdom, believed by the majority of programmers without critical examination, and based on very performance-poor early microkernel designs like Mach.

The truth is that modern microkernel designs like L4 can perform IPC over 20 times faster than Mach. Another important advance for microkernels are tagged TLBs which can alleviate the TLB misses that are usually incurred on every context switch.

Someday, hopefully not too far in the future, someone is going to write a modern, practical, and free microkernel-based OS that implements all of POSIX with performance the rivals Linux, but that offers a level of isolation and modularity that Linux could never offer. When that happens, a lot of people are going to scratch their heads and wonder why they believed the people who told them that microkernels are "fundamentally" slow.

I had hoped that HelenOS would become this (http://www.helenos.org/), but its lowest-layer ipc abstraction is async-based, which I think is a mistake. One of L4's innovations was to use sync IPC, which offers the highest possible performance and gets the kernel out of the business of queueing. You can always build async ipc on top of sync without loss of performance; this puts the queues in user-space which is where they belong (they're easier to account for this way).

I asked the HelenOS people why they decided to go this way, and this is their response (one of their points was "the L4's focus on performance is not that important these days", which I disagree with). http://www.mail-archive.com/helenos-devel@lists.modry.cz/msg...
Ask HN: Would you use a "Pandora for local artists"?
This weekend, I hacked together a prototype of a web app I've been thinking about for a while - an online radio station that only plays local music. I live in Boston, and we've got an amazing (and huge) local music scene. I love discovering local music (there's not much that compares to the feeling of watching an unknown band absolutely kill a show in some basement in front of 20 people), but I haven't really found a way that's not clunky. I'm lazy - I just want to be played a bunch of local artists, and I want it to be easy to keep tabs on the ones I like (follow, buy tickets, etc).

I've been in bands since I was in elementary school, and there's always this point you get to where you've told everyone you possibly can about your new EP/track/show. Your growth sort of flatlines, and it's not easy to get it to accelerate again. The biggest problem is just getting your music in front of people that haven't heard it before - it's a logistics problem. Like it or hate it, you don't get anywhere if nobody hears it.

So I built Radius to fill these two needs simultaneously. Local artists get a new venue of exposure (a lot like "local hours" on college radio stations - remember radio?). People (like me) get a great, simple way to find and follow local bands. Win-win.

Anyways, I opened Radius up to artists in Boston last night and was really blown away by the number of signups. So with this post, I'm trying to test the other side of things. How many of your enjoy finding new local bands? Would you use something like this to do it? Are any of you artists yourself? Would you welcome a service where you could put a track in front of people in your city?

Would love to hear your thoughts/criticism/awesome ideas. Thanks in advance!

Cheers,
Alonso from Radius

*
If you like the concept and would like to help beta-test in a few days, there's a signup page at http://getradi.us
If you're a musician and you'd like to feature a track, check out http://getradi.us/signup
As an aside, good god is the new support section on Microsoft.com criminally gorgeous.

They really went above and beyond in the redesign. It feels wrong to take this amount of pleasure in reading a support knowledge database.
maybe some years ago Berlin was much cheaper, but rents are getting more expensive everyday. Still cheaper than London though.
So, don't talk to you about your PhD at all?
I understand someone would expect his close friends not to ask those questions, but you can't seriously hope the average people will know what to tell you.
You could just ignore the "wrong" question and answer it properly:

a) When are you going to graduate?
- I can't know for sure, but I hope it will be in two years or so.
b) Do you have such and such holiday "off"?
- No.

And no matter what you tell me, I can not accept you saying that "you must be so much smarter than me" is offensive. Even if I don't like hearing that myself.
Gist: jQuery update plugin
This approach to the "do" syntax requires that the function implementer know the monad type a priori.

That defeats some of the purpose of monad as general abstraction. One of the big ideas here, as far as I'm concerned, is that monads represent an abstraction over a common structure of programs. Lists, Maybes, threading models, etc, all share this same language of structuring computations. This is significant because it means that one can build functions which manipulate those structures, and then those structures can be deployed generically. Depending on how you're counting, that means third-order abstraction.

For instance, consider liftM from Control.Monad:

-- | Promote a function to a monad.
liftM :: (Monad m) => (a1 -> r) -> m a1 -> m r
liftM f m1 = do { x1 <- m1; return (f x1) }

This represents a common idea across e.g. both List and Maybe. I've got a function of values. I want to turn it into a function of Lists / Maybes. Well, liftM recognizes the similarity of List's and Maybe's structure and provides a single implementation suitable for both places.

The decorator described in this article cannot function at liftM's level of abstraction: at least as far as I can tell (as a non-Python programmer), it requires a monad type parameter. If that's true, I think it's missing a key idea behind the power of monads.
I don't see that as inconsistent at all. Why can't you be pro-free-market and anti-union? You can agree with the concept of a free market, but disagree with how unions currently operate. You appear to be confusing "I hate how unions tend to behave" with "I think unions should be forbidden".

I think unions can do great things to protect the workers they represent, but I hate that many (most?) of them seem more focused on things like retirement benefits and policies that have the effect of making it difficult to impossible to fire bad employees.
1. Decide which country 2. Start a blog (AnAmericanSysAdminInBerlin) about what you intend to do 3. Ping a number of startup and established companies (follow them in twitter don't get spammy) and be clear you are an expert in xxx 4. Prove it by working remotely on short term gigs

This seems like a rather convoluted way of finding a job. May be what you mean is find an effective way to communicate that you have xxx skills and find companies that may be in need of it? Starting a blog may be one way but I have my doubts if its the optimal thing in his case.

Also, I'd actually say that OP might as well begin by applying for published jobs. You will get some baseline idea about the market or culture(do recruiters in blah region even reply? what are the responses like? etc.)
I think it would be a very good idea to make such scripts for other distros as well, and to test the living hell out of them. Your installation procedure is your biggest problem (just look at the size of the thread here), and you should fix it.

I've just spent the last 5 (five!) hours trying to setup GitLab, and I just don't get it to work. And I ain't no rookie either. This is the second time in about a year that I spent so much time trying to get this to work, and I'm about to give up on this project. I want this to work, and I want to use this, but this is insane.

I actually did a dist-upgrade from Lenny just to get this to work, and I made it through all the arcane steps (somehow) - but nothing. I can't get it to work. I can connect to GitLab, it redirects me to 'users/sign_in', and then it just crashes ('Killed', it says). Yup. Tough luck for me. That's five hours down the drain.
The question to the audience is, shouldn't a free market advocate want to reduce both the laws which give unions specific power AND those which take power away from unions?

Yes. I'd love to scrap all laws relating to unions and have the law treat them as worker-owned consulting companies.

Is an employer a sort of monopolist? I believe they are. While there are exceptions (IT in the Bay Area during the dot-com era being an obvious one), for many people it is not easy to quit and easily find new employment. Otherwise Nevada wouldn't have a 10% unemployment rate.

Can you explain this claim? What prevents any employee from leaving and selling their labor to another willing party?

Many people find it difficult to leave and find higher paying work, but that just means their current employer is paying them at or above market [1].

Unemployment is (according to Keynesians at least) a mismatch between employee's desired wages and market wages. It has nothing to do with monopoly power. A simple way to test this - is unemployment higher in sectors with a smaller number of firms?

[1] A common reason for this is the accumulation of firm-specific knowledge. That is to say, an employee's value to the employer is X+Y, where X is general knowledge (useful to all employers) and Y is useful only to the current employer. I.e., X is general programming, Y is knowledge of a specific legacy system. This is a situation with both a monopoly and a monopsony - the employer can't find outside employees with legacy system knowledge and the employee can't find outside employers with that specific legacy system.
Yes, because "must sort quickly" is the only important requirement in a systems level language.
Every public web site on the planet is "accepting data from an untrusted remote client" - but allowing public db access is something else entirely.
I'm fashinated by Combinatorial Optimisation (I'm followinf course, too). Do you have other article or interesting resource about that?
Linux Mint 14 “Nadia” KDE released
Netrunner Linux 12.12 released
You are correct - the 2nd amendment prohibits the US government from infringing the right to "to keep and bear arms" - it does not specify what kind of arms, so knives and swords (and theoretically but not actually) nuclear weapons would all be equally covered - supposedly as a check against tyranny, but this is not spelled out in the constitution, and sedition was made illegal about 10 years after the constitution was ratified.

My personal view, therefore is that the arguments for the 2nd amendment are a ridiculous fiction - as I imply above, US citizens can not actually build up an arsenal of weapons that would enable them to successfully challenge the US Government successfully (see Waco, Move, etc. - build up a big enough armory, you will be taken out).

So in my view gun rights only exist at this point to enrich arms dealers and give the citizenry an illusion of control, at the low, low cost of 80-something of our citizens per day.
>Your statement is what I mean. "Thinking things through" should be done during design. Once you have built system, its much harder to compensate for design flaws.

I agree with this fully. This is something that would need to be solved before building such a system.

A great example of a system which learns from history, but which also supports changes in behaviour is: http://worrydream.com/MagicInk/#engineering_inference_from_h...

The linked example is specific to one application, but he continues to detail what he thinks would make for a general solution.
from Spaghetti code to Ravioli code
I recommend the "STEPS Toward Expressive Computing Systems" reports for more current-day thoughts on OS redesign (available here http://www.vpri.org/html/writings.php )

Basically, by designing exactly the necessary language for each layer, they've reduced the code requirements to reach useful applications by multiple orders of magnitude.

I honestly wouldn't be surprised if the results of this project eventually creep into industry.
I have never found making something a configurable setting to solve any problems. All it does is push the decision forward to what the default should be, given that 99% don't change it.

Design is about making decisions. Trying to duck that leads nowhere.
The Christmas Experiments - Never Seen The Sky (Chrome/WebGL)
Scored a 70 with my less-than-great laptop screen.

The problem with any of these online tests is that it is skewed based on your monitor, graphics card, OS, and browser settings.
One thing that's interesting is that, while microkernels haven't really won, Xen-style paravirtualization, which in a way is an even more radical version of the de-monolithization idea [1], has taken over in a lot of niches, despite performance being an even bigger problem, especially without hardware assistance.

[1] This paper, for example, argues that VMMs are "microkernels done right": http://static.usenix.org/event/hotos05/final_papers/full_pap...
Zed Shaw's Template for "Learn X The Hard Way" Books