Pizza Cook job listing at Apple - <AUTHOR> http://jobs.apple.com/index.ajs?BID=1&method=mExternal.showJob&RID=114974&CurrentPage=7

<comment><USER2> > The cook will also prep and maintain all food items necessary to make a > variety of pizzas (toppings, sauces and related prep).

Maintainable food items.

"Also, the cook should be able to test these modular food items to ensure they are _bug_ free."

<comment><USER3> "A successful candidate will have 3 years experience using Test-Driven Cooking."

<comment><USER4> "Employee performance will be judged by the number of Recipe Lines Of Code (RLOC)"

"Candidate must be familiar with high-level Recipe Markup Languages such as XPL (Extensible Pizza Language) and JSRN (JavaScript Recipe Notation)"

<comment><USER5> Candidate must be familiar with Agile cooking methodologies (the head chef is known for throwing things when angered).

This job does not use RESTful cooking practices.

</comment></comment></comment></comment><comment><USER6> I wonder if they'll have an employee spend months in a room designing the perfect pizza box opening experience...

Clean, minimalist design

Notches to facilitate stacking while preventing damage

No cheese on the cover

Pizza does not shift while in transit

Easy to lift and re-close cover without damaging pizza crust

Box stays warm but doesn't get too hot

Channels delicious pizza smell directly outward toward consumer

<comment><USER4> However, it's only available in one size, and the other flavour - announced at launch - actually takes a year to become available.

And you are required to have an Apple ID to open.

<comment><USER7> And the black pizza costs 100$ more.

<comment><USER4> And if you order online, you can get your name engraved into the pizza, free!

</comment></comment></comment></comment><comment><USER8> I'm glad this an Apple listing and they're not farming this position out to a third party. Reminded a tad of the Zynga hubbub about the Google chef, one of their most valued early employees:

[http://blog.rongarret.info/2011/11/in-defense-of-google- chef...](http://blog.rongarret.info/2011/11/in-defense-of-google-chef.html)

<comment><USER9> Reminds me of when Exxon Mobile had a job posting for their Pizza Chef when they were the largest company in the world... wait, they definitely farmed out their pizza boy to a sub sub sub sub sub contractor. Good to see the largest corporation in the world still have at least a little heart :)

</comment></comment><comment><USER10> Having eaten there a couple of times, the pizza at the apple cafeteria was good. We would always comment on how the pizza chef was about 5ft tall. Perfectly sized to look in the oven w/o leaning over. Form following function in one way or the other. The job post doesn't discriminate this way...

</comment><comment><USER11> I wonder if by neapolitan style they mean what New Yorkers call neapolitan pizza (what other Americans call New York style) or literally pizza from Naples. I assume the former, but either way this is making me hungry.

Apple should make this mandatory reading: <http://www.varasanos.com/PizzaRecipe.htm>

<comment><USER12> Why do you say that? Can you confirm what Jeff V is saying is not bullshit?

</comment></comment><comment><USER13> I am just curious; what would most likely be the salary for this position?

<comment><USER14> Yeah, seems like someone with 4 years experience with high demand brick oven/pizza tossing skills could make a killing on their own considering the mark-up on pizza.

<comment><USER15> Except pizza (well restaurants in general) is one of the most competitive markets there is. If you manage a 5% profit margin you're doing really well.

<comment><USER13> So that essentially means that pizza tossing skills is not high demand?

</comment></comment></comment></comment><comment><USER16> anyone else notice the job was in sacramento not cupertino? what type of office do they have in sacramento?

<comment><USER17> They used to have a manufacturing facility there (Elk Grove suburb of Sacramento), now it's an Apple Care call center and probably some other stuff.

</comment></comment><comment><USER12> The funniest thing about this is that Apple, a company known for innovation, is just following the herd and assuming that you need a high-temp oven and to be able to stretch the dough "by-hand" to make a good pizza.

OR

They know it's BS but know marketing is just as important ;)

</comment><comment><USER18> Yes, Apple employees eat food. Some of them might actually like pizza. To provide good pizza, you need to hire a pizza chef. Is this really something "that gratifies one's intellectual curiosity"?

</comment><comment><USER19> Whoa.. a combination of my two favorite things, technology and pizza. I need this job.

A nice high hydration dough with a 3 day cold ferment. San Marzano tomato sauce.

<comment><USER20> Yes, my favorite VPN had nothing to do with networks. You might find some of this interesting, if you haven't seen it already... <http://www.varasanos.com/PizzaRecipe.htm>

edit (in case you don't know): VPN -> pizzanapoletana.org/index_eng.php

<comment><USER21> You deserve many more upvotes than I can give for that link! I just lost the last two hours at work reading and salivating.

</comment></comment></comment><comment><USER22> I ended up at the Apple building in Sacramento after winning a holiday America. Pizza was good and the workplace seemed a pretty fun place.

</comment><comment><USER23> so they have to make the dough, prep the sauce and toppings, stretch the dough, cook the pizzas? Is this a team of one?

<comment><USER24> Yep. Pretty much any pizza-shop employee does those things. Obviously not all at the same time.

</comment></comment><comment><USER25> I'm working for the wrong company.

</comment><comment><USER26> Amazing

</comment><comment><USER27> There's got to be an app for this.</comment>


CeBIT '17: Edward Snowden "Datasecurity and Privacy in the Age of Surveillance" - <AUTHOR> https://www.youtube.com/watch?v=9vgVvTBirpg <comment><AUTHOR> I was there and have to say I quite enjoyed the talk overall and would recommend to watch it if you're interested but let me just tell you about one particular moment here.

The hall was loaded with attendees eager to listen in, chairs were moved from the hall next door to accommodate the sudden influx of people but even then people had to stand all the way to the back. I particulary remember when he started speaking about.. well let's say his motives and beliefs starting at 50m56s up to 52m53s. The audience was captivated. If someone would have dropped a needle there you'd hear it, that's how silent everybody was. There were full rows of journalists typing eager on their keyboard at all times but I saw nobody type here, they all were listening to what he said. It was quite.. surreal - in loss of a better word[1] - to look around me, seeing every single attendee listening so closely to what he said.

[1] Not a native speaker, not sure how to express myself here but I thing you get the gist.</comment>


NK fails to put satellite in orbit - again. - <AUTHOR> http://www.space.com/missionlaunches/sfn-090406-north-korea-launch.html

<comment><USER2> The weird thing is they think they _have_ done it:

        "Our satellite is transmitting the immortal revolutionary paeans The Song of General Kim Il Sung
        and The Song of General Kim Jong-il as well as measured information to the earth," the Korean Central News
        Agency reported.

<comment><AUTHOR> This link: <http://www.armscontrolwonk.com/2242/another-failure> shows the splash-down site. And they have an amusing (to me anyway) interpretation of that remark.</comment></comment>


The Cost of War - <AUTHOR> http://costofwar.com/en/

<comment><USER2> This is off by 5-10x if you count all the costs (equipment, increased domestic costs, ongoing security liabilities, ...)

<comment><USER3> It also completely discounts the human cost of warfare, if such a thing is even measurable.

<comment><USER2> Definitely. Even if you just focus on the economic cost of the human costs (lost income for anyone who dies in early 20s, disinvestment in Iraq/Afghanistan by local people due to fear they'll be robbed or killed, etc.), that's higher than the direct military cost.

</comment></comment></comment><comment><USER4> Can we just start listing government costs debts, etc. on a per-capita basis? Aside from the fact that we can then compare differently sized governments, it just gives a better sense of scale. When you multiply by 300M just about all numbers are mindlessly big.

</comment><comment><USER5> I'd like to see the war on drugs added.

</comment><comment><USER6> Why is this on Hacker News?</comment>


A Year Away from Mac OS - <AUTHOR> http://bitcannon.net/post/a-year-away-from-mac-os/ <comment><USER2> I also migrated away from MacOS. I'm currently running Linux (Slackware). I came to the conclusion that Linux works best for me on desktops, but MacOS works better on laptops. I don't use laptops much anymore, I prefer multiple monitors, I don't like the way MacOS handles multi-monitors.

I ended up buying a couple of used Dell Optiplex 9010's for a little more than $100 each. Also picked up a couple of Thinkpad X220's also about a $100 each. They all run faster than my Macbook Air.

Tried all of the Linux distributions, didn't really like any of them (I hated Ubuntu and all the variants). So I installed Slackware, I use a customized FVWM (as in I hacked the source code). Removed things like PulseAudio and NetworkManager. I use a customized version of Gnustep (just the Foundation part) because I need Objective-C. And I wrote a bunch my own UI using Cairo (not a fan of GTK or Qt).

I still use MacOS on my Macbook Air, but more as an appliance and not for anything serious. I feel much more comfortable with my computer now (I am no longer dependent on Apple!)

<comment><USER3> Did you try Debian or Arch? I tend towards Debian but I realized the time I spent with Arch, too.

<comment><USER2> I used to run Debian but my packages would always end up in some kind of dependency hell where I couldn't upgrade to newer versions.

<comment><USER4> would it be possible for you to share your fvwm hacks? i too run fvwm (on arch) and was wondering what i might be missing out on ?

thank you :)

</comment></comment></comment></comment><comment><USER5> People move around, and that's fine. After two decades of mostly using Linux, I just made a leap of faith into the walled garden of Apple, replacing pretty much every Linux and Windows box with either nothing (the best choice!) or a Mac.

It's just a month in, but I'm quite happy. Everything works and everything is pretty. I can concentrate on important things, and of course on social media shilling.

<comment><USER6> I've done the same 2 years ago, after being Linux-only for two decades.

Sure, macOS has its flaws. Sure, GNU command line tools are better than the BSD ones (fight me). Sure, it's not as hackable as a Linux machine.

But I've never been as productive. Everything works, I'm not fighting any hardware issue — Bluetooth? Wifi? Resume from sleep? Hell, I'm even rocking an external GTX 1080 GPU via Thunderbolt 2->3 adapter, and playing 4K games in Bootcamp.

I have a 16GB rMBP 2015, which probably is the last well made MBP, since the newer revisions seem to have so many issues, but I don't see myself going back to a Linux desktop ever again.

To be honest, the only two things I miss that work really well on Linux are Docker, and Wifi packet injection (aircrack-ng & co.)

<comment><USER7> Do you have a recommendation for an external GPU enclosure? I have the same model MacBook as you but I've been hesitant to pick one up.

<comment><USER6> I have an Akitio Node. It's noisy as hell, but fits a full sized GPU and quite hackable - there are some silent fans mods if it bothers you.

There are plenty of gotchas, so make sure you read up on egpu.io and /r/eGPU

But once setup, and when Windows doesn't break everything with an update (happened with the Fall Creators update), works great and performance should be within 90-95% of a desktop setup, provided you're using an external monitor. You can use the internal LCD, but TB2 bandwidth will be the bottleneck in that case, and you'll get a bigger performance hit.

Here's my success post on reddit: [https://www.reddit.com/r/eGPU/comments/77e86g/success_macboo...](https://www.reddit.com/r/eGPU/comments/77e86g/success_macbook_pro_15_2015_tb2_akitio_node_gtx/)

</comment></comment></comment></comment><comment><USER8> > The Dell power connector is a barrel style connector with an LED embedded in > it. The LED appears to serve no useful purpose. It's always on, whether > connected or not and doesn't change colour or turn off when charged.

I believe the only use for this LED is to know that the cable is actually plugged to the wall. It's probably useless for people who keep their charger plugged all the time, but it's very useful for me, a QA engineer with a testing table full of devices and cables, plugged and unplugged :)

</comment><comment><USER9> I totally understand the shift in thinking that you get when you become immersed in open-source - you realise how it's possible for all the elements of your system to play well with each other because it's possible for the authors of the software to understand how the kernel/OS/apis/drivers etc. work to a deep level. Once you get used to this, proprietary software starts to take on an appearance of a socially-oblivious actor on your system, needing special attention to keep it fitting-in.

You might want to check out the MATE desktop. It's a fairly no-nonsense desktop which also looks quite nice (see ubuntuMATE - especially with the arc themes). I keep going back to check out gnome, but while I admire the polish, I find some design decisions to remain a bit grating.

</comment><comment><USER10> > The thing I dislike about the XPS the most is probably the power connector. > I miss the ease of attachment and feedback of MagSafe.

Well I still don't understand Apple's decision to axe MagSafe. It was a huge selling point of MacBooks. While I don't miss it sorely, the USB-C plug just gives me no joy.

<comment><USER11> MagSafe could be sometimes unreliable. USB C is fun too. Although I don't like other aspects of the MBP. Like it's keyboard.

<comment><USER12> Very occasionally I do have to plug then unplug then plug back the magsafe connector in order to power up my 2015 macbook, however the magsafe design has saved my laptop from certain damage many, many, many times. Literally, the only reason for removing it from Apple's point of view is that it saves too many laptops from needing replacement/costly repair.

</comment></comment></comment><comment><USER13> The gnome JavaScript rant is real. I had to move on to kde plasma because of it. Kde plasma is more powerful but a little cluttered. Gnome has managed to keep things very simplistic. There is a silver lining though, gnome4 has plans to ditch js.

<comment><AUTHOR> > There is a silver lining though, gnome4 has plans to ditch js.

This is intriguing. Do you have a link to more info?, I can't seem to find anything.

<comment><USER13> [https://wiki.gnome.org/Initiatives/Wayland/GnomeShell/GnomeS...](https://wiki.gnome.org/Initiatives/Wayland/GnomeShell/GnomeShell4)

</comment></comment></comment><comment><USER14> I've been using Gnome for about three days now, and I'm incredibly irritated with all the minor things.

Attempting to drag something from the Activities bar to the desktop results in the whole UI crashing, taking down all applications with it.

Trying to set the screen to wait more than 15 minutes to power off required googling up a StackOverflow answer. Why is there not a text input option for this?

I'm sure I'll discover something stupid tomorrow.

<comment><USER15> Have a look at KDE Plasma. They've added a lot of polish to it, and it's superb. It's been my daily driver for the last year or so, haven't had as much problems as I did with GNOME.

<comment><USER14> Thanks, I'll give it a shot, and hopefully not amend this comment with a paragraph bitching about switching :p

</comment></comment></comment><comment><USER16> > but I've still seen a couple of the MacBook keyboards fail in their short > life. One had a key become sticky and unreliable, the other had its space > fall off.

The return key on my 2 month old 13" Macbook Pro has already lost its "click". A couple of times a week I have to reboot it to get sound working again. Plugging external monitors in is a coin toss. I have to carry an external dongle around to use it and the dongle gets noticeably warm when in use: what's going on in there?

<comment><USER17> My MBP keyboard degraded over time, only 2 years in. Started with WASD (hehe) and spread outward until nothing worked. I plugged in an external keyboard and soldiered on. One day I bootcamped into Windows and something went wrong. I got completely locked out because apparently the internal keyboard is the one and only way to get the boot menu. I understand repair would cost $250+. Very disappointing since my previous MB lasted 9 years.

<comment><USER18> Was it the 2015 13" by chance? Those were known to go bad quickly.

<comment><USER17> 2013 13", but probably the same general issue.

</comment></comment></comment></comment><comment><USER19> Wow, I'm in the exact same situation.

Using Xfce and loving it so far, went through every single distro in existence.

Cool series!

<comment><AUTHOR> Thanks! What OS/distro did you settle on?

<comment><USER19> Personally, Xfce heavily configured to my liking, on top of Ubuntu Minimal (basically, I took the Minimal CD and installed xorg and xfce4-session).

In particular I've installed DockbarX--a dock that integrates into xfce4-panel, and vala-panel-topmenu (or somithing similar) to have a global menu.

</comment></comment></comment><comment><USER20> I've been a UNIX user since 1984, I've been using Apple as my personal hardware since about '87

I jumped from Mac OS due to cost of Apple Hardware, last year. I can't justify spending $3K for hardware that if it weighed 1lb more costs $650.

I bought a Quad core i7 Gaming laptop, Dual SSD's, 1080p display, 32GB of memory for $800, yay Black Friday. My original plan was to make the machine into a hackintosh, but while waiting for the WiFi daughter board to arrive from China I decided to install Linux.

I tried a number of Linux variants. I ended up settling on Elementary because it was the only distribution that would consistently "wake up" from hibernation or sleep. Every other distro would cause the machine to hang after hibernation or sleep, I spent a lot of time trying to make other distributions work, but to no avail.

I did get the WiFi daughter board and installed it, but I never seem to get around to creating my hackintosh.

I'm completely happy with my Linux laptop. Elementary has a couple of quirks, but nothing that makes me want to switch. The online version of Microsoft office allows me to interact with Office documents, which was always the biggest stumbling block, at least for me when it comes to Linux.

<comment><USER21> > I can't justify spending $3K for hardware that if it weighed 1lb more costs > $650. > [...] > I tried a number of Linux variants. [...] I spent a lot of > time trying to make other distributions work, but to no avail.

Just curious: What kind of value are you putting on your time ?

Admittedly, I can perfectly understand if you consider tinkering with distros an intellectually gratifying pursuit and therefore time well spent; I just wanted to point out that it would NOT be all that hard to justify spending an extra $2K.

</comment></comment><comment><USER22> You are crazy —- the good kind of crazy tho —- for moving away from MacOS on your work machine.

I'm just a dabbler in all things Linux/sysadmin/IT who tried going from Windows to Linux as my desktop and did well until it came to dealing with X and graphics drivers for my aging nvidia 660. Sure I got everything up and running just fine with hardly any effort but just basic things like hardware acceleration in browsers and screen recording software were a giant pain in the ass that took entire weekends for me to only half way solve. Still, it taught me a lot more of how Linux has evolved since the dark days of floppy based Slackware and redhat installations. Give the people responsible for Quartz on OS X and the Windows GUI a kiss for me, bless their hearts. The year of Linux on the desktop will come when we can move away from the ancient parts of X and flatpaks are perfected.

</comment><comment><USER23> > If anyone is interested in a paid project to build an open source command > line replacement for my use of MoneyWell in Rust

Don't know if you've seen this, but as you mentioned a command line accounting system...

[https://www.ledger-cli.org/](https://www.ledger-cli.org/)

It's an open source command line accounting system (though it is written in C).

<comment><AUTHOR> I looked at it. As far as I can tell it doesn't do envelope budgeting with automatic flow. This is the key feature to me and why I went with MoneyWell back in 2008.

<comment><USER24> What do you mean be automatic flow?

You can pull off envelope budgeting: [https://frdmtoplay.com/envelope- budgeting-with-ledger/](https://frdmtoplay.com/envelope-budgeting-with- ledger/)

</comment></comment></comment><comment><USER25> I used Linux (mostly Ubuntu) for somewhere around 10 years on my personal laptops. After using Macs at work for a few years and being frustrated with the music making and photography apps on Linux I made the switch about 3 years ago. There just wasn't anything on Linux that had the polish and ease-of-use of Photos.app and GarageBand/Logic and when I want to engage in creative hobbies, I want my technology to just work. Has Linux made any progress on alternatives to those?

</comment><comment><USER26> Consider some alt operating systems. OS/2 is still out as econ and Blue Lion. AROS is based on AmigaOS 3.x, Haikuos is a rewrite of Beos, Reactos is a rewrite of Windows XP, and FreeDOS is a 32 bit DOS. You can Google them and try them out.

</comment><comment><USER27> There's something about reading a blog in monospaced font...

Enjoyed the article very much. The macOS / Linux / Windows switcherooney debate has been going on for years with me. The new MBPs make it an easy choice but Linux on the desktop (T470s recently purchased) makes me less productive than macOS on a 2015 MBP.

I've switched away from this MBP no less than 4 times to 4 different Linux laptops and each time have come back after roughly 1 month. It sickens me (I work for Red Hat so FOSS is quite deeply ingrained) to work on a Mac every day instead of respecting freedoms but sometimes you just need to get on with it.

</comment><comment><USER28> I ran FreeBSD on my home and work desktops (and most of my servers) for almost 10 years. I use a Mac these days, but I still have a soft spot for FreeBSD on the desktop.

For Dropbox on FreeBSD, I found just installing the CLI (pkg install dropbox- api-command) and then calling "dropbox-api sync" in cron ever 10 minutes was good enough.

<comment><AUTHOR> Interesting. I was aware of the CLI but didn't know it worked on FreeBSD.

</comment></comment><comment><USER29> This links to an abstract, but I can't find the actual blog post.

<comment><AUTHOR> It works for me. What are you seeing? (Feel free to email wes AT wezm.net)

<comment><USER29> Sorry for the noise. I thought it was a table of contents for your blog, but now I see that it is actually the March 2018 post with a bunch of sub-heads.

</comment></comment></comment><comment><USER30> If only a stable *nix desktop OS could run a webex meeting I'd switch my devs over. But noooo it's a 10 year old java applet.

</comment><comment><USER31> I've been thinking about doing this too. Great write up.

</comment><comment><USER32> Wow so much hate for the MacBook</comment>


Ask HN: What is your approach to donating to nonprofits? - <AUTHOR> For example: All things equal, do you try to consolidate and make your donations to the best organization on the issue you care about, or do you try to widely distribute the donations to as many suitable organizations on the issue as possible in order to maximize the number of approaches to the issue? How do you judge donation options as best/good/bad - particularly, are there non-obvious factors you look at?<p>Thanks <comment><USER2> I first look on the stability of the organization and then see their work history. After which I personally call them.</comment>


OwnCloud Statement concerning the formation of Nextcloud - mike-cardwell https://owncloud.com/owncloud-statement-concerning-formation-nextcloud-frank-karlitschek/ <comment><AUTHOR> I have rarely seen an instance of open source project forking which immediately causes loss of employment of eight members of original team.

I _have_ seen such forks degenerate hugely into "they said / we promised / they suck / we're awesome", so I understand the need to delicately balance press releases between the need to inform and need to keep it civil/diplomatic, but I wish I understood more why the act of forking has caused their credit to disappear.

      Unfortunately, the announcement has consequences for ownCloud, Inc. based in Lexington, MA.
      Our main lenders in the US have cancelled our credit.
      Following American law, we are forced to close the doors of ownCloud, Inc.
      with immediate effect and terminate the contracts of 8 employees."

<comment> mike-cardwell In the first sentence they sound very bitter: "using recently poached developers" \- Almost as if they're trying to say that poaching developers is a bad thing. Developers are people, you don't own them and they owe you zero allegiance.

<comment><USER2> Actually, I should add that to my CV "poached developer" ;-)

\- Lukas (Nextcloud'er - see also [http://www.zdnet.com/article/owncloud- founder-forks-popular-...](http://www.zdnet.com/article/owncloud-founder- forks-popular-open-source-cloud/))

<comment> mike-cardwell Whilst I have your attention ;) Are there any plans to add CalDav/iCal client functionality to NextCloud? I'd like my NextCloud server to sync with external calendars (E.g my work Google calendar) so that I only have to point my client devices at my own server.

<comment><USER3> I strongly recommend radicale with DavDroid. I've been using this set up (that only took a few minutes to complete, especially with Caddy for TLS) for months now with great success.

Radicale will also automatically commit every change into a Git repo, so you can always go back to any point in time. Just amazing.

[https://www.stavros.io/posts/private-contacts-and- calendars-...](https://www.stavros.io/posts/private-contacts-and-calendars- android/)

<comment> mike-cardwell Radicale sounds interesting, but it looks like it's just a CalDAV server? OwnCloud/NextCloud already gives me that. What I'm looking for is a way of syncing calendars which _have_ to be off-site, to my own server. I don't have control over the fact that my company uses Google calendars for work and I'd like to dump my Facebook events into an OwnCloud/NextCloud calendar too.

</comment></comment></comment></comment></comment></comment><comment><USER4> My guess is that the governance and decision-making of owncloud inc, coupled with commercial debt/obligations they chose to take on, made it impossible to become commercially successful. Once the writing is on the wall for the main devs, why stick around? You can spin the code out to an unencumbered corporation (nextcloud), leave the debt behind you (owncloud), and start with a clean slate and new governance model.

That could be close or far from the truth, but one thing is clear: the 8 devs who left couldn't see a path to solvency (technical and financial) that was reachable. The most likely reasons for this are either economic realities, or inadequate political capital.

I hope they do better in their new positions.

</comment><comment><USER5> Developers don't get "poached". They're not deer. The leave because something better is offered to them. Usually much better.

There's much more to this than we know yet.

</comment><comment><USER6> Sad to hear that the US-based employees were let go. I live in Lexington, and run by that office quite often, so it kind of hits home. Best of luck to all of you.

<comment><USER7> I'd prefer you'd phrase it "were laid off" or "fired" instead of "let go". The later is an euphemism that implies some kind of free decision.

</comment></comment><comment><USER8> This entire thing is just bizarre, I feel like there's a lack of openness from both sides in their communication. No side tries to inform their users about what really happened. I guess the best case is that one side (or both) can't talk because of legal proceedings which, again, would be strange for a more or less open source project.

<comment><USER9> Well, legal stuff and also you just don't badmouth people you worked with until recently. It's simply not nice, and we are still friends with some of the Inc employees.

For more info I recommend the Q&A from Frank and Jos today: [https://youtube.com/watch?v=iMfokaX2r8g](https://youtube.com/watch?v=iMfokaX2r8g) – we try to be as honest as we can.

Disclaimer/source: I'm one of the »poached developers«, or rather the designer. ;)

</comment></comment><comment><USER10> Bizarre...seems like it was a hastily-put-together press release.

</comment><comment><USER11> That escalated quickly.</comment>


Goldman Sachs Recasts Its Reputation to Woo Tech Talent - <AUTHOR> http://dealbook.nytimes.com/2014/11/13/goldman-sachs-recasts-its-reputation-to-woo-tech-talent/?hp&action=click&pgtype=Homepage&module=first-column-region&region=top-news&WT.nav=top-news

<comment><USER2> This "article" is a barely-concealed advertisement for technology job opportunities within the company. I predict that they paid the NY Times for this article.

There is no mention of legitimate reasons why someone would not want to work for Goldman Sachs, namely their horrendous reputation for market manipulation, political bribery, and profiting from the financial crisis.

[http://en.wikipedia.org/wiki/Goldman_Sachs#Controversies](http://en.wikipedia.org/wiki/Goldman_Sachs#Controversies)

</comment><comment><USER3> It's finance industry. It may even be challenging on the technology ground, but there's no mission and purpose behind, just making someone make big bucks. Quite the opposite in Sillicon Valley, I suppose, where one can build something that actually affects the world.

It's hard to force self to like an abstract problem if one didn't like it on its own.

<comment><USER4> > but there's no mission and purpose behind, just making someone make big > bucks. Quite the opposite in Sillicon Valley, I suppose, where one can build > something that actually affects the world.

This is not universally true. One can find examples of SV companies that are not doing important things that affect the world (e.g., "Yo!") and one can find people on Wall Street who are making money and using it to affect the world (e.g., James Simons and the Simons Foundation).</comment></comment>


OpenSesame – A device that can open fixed-code garage doors in seconds - <AUTHOR> http://samy.pl/opensesame/ <comment><USER2> Three weeks ago I reverse-engineered my garage door opener wireless protocol. I probed the remote's PCB with a Saleae logic analyzer and found it was a 12-bit code ASK-modulated at 390 MHz with bits encoded as sequences of 10 kHz and 20 kHz pulses. I bought a $13 spare remote to hack it and control the RF transmitter section from my computer through an FT232 sending the ASK signal. I just cut off the digital signal trace going from the MCU to the RF transmitter and hooked it to the FT232. I built a brute-forcer and it works quite well. I do not have my notes at the moment, but IIRC one code takes 25.6 ms to be sent. And my manufacturer (Genie) seems to require the code to be transmitted 4 times consecutively to open the door, that's 102.4 ms. Multiplied by 4096 combinations, this gave me a brute-forcing time of 7 minutes.

I had tried Samy's exact attack to reduce the brute-forcing time but it did not work at the time because I tried it before I discovered the code had to be sent 4 times consecutively (5 times makes it more reliable due to RF interferences). So I am not surprised to see Genie absent from the list of models Samy found vulnerable.

But I should try to find out the longest period of time during which these 4 repetitions of the code need to be sent. Maybe it does not have to be perfectly consecutive, but it could be 4 codes received within an interval of 200 ms or 1000 ms. If so it might still be possible to build a modified De Bruijn sequence that repeats codes 4 times while being only 4 times longer.

By the way it is very surprising a description of the 12-bit Genie protocol does not appear to exist online. These remotes are so easy to reverse engineer, so common (Genie is in the top 3 or top 4 most common openers), and so old (the protocol has existed since 1985), you would think there would be information about it online, but nope.

PS: I wonder if there could be commercial interest in cryptographically secure garage door openers? A $0.50 ARM Cortex-M0 MCU is all you need to implement a HOTP based on HMAC-SHA1. Then a simple learning/pairing system writing the key in EEPROM can even sustain the battery being removed from the remote. But there is probably no interest... which is why most remotes are insecure even the "rolling code" ones.

(Edited to clarify some tech details.)

<comment> at-fates-hands >>> I wonder if there could be commercial interest in cryptographically secure garage door openers?

Probably not. Mainly because breaking a window or crowbarring a door is a lot less expensive and a lot faster.

<comment><USER3> Was thinking about making the same comment. People throw cinderblocks here to get garage doors open. Until recently, we deliberately kept ours unlocked (if we're going to get burglarized, at least we'd like to keep the doors on the hinges).

<comment><USER4> I had to do that when I worked in San Francisco. I just left it open with a note, "Please take a nap in here, whatever, just don't break anything." I did put a kill switch in that mechanics can't figure out. It wasn't the stupid radio I cared about, it was repairing the windows.

</comment></comment></comment></comment><comment><USER5> > It may be time to upgrade your garage door opener.

If you're worried about this, make sure your garage door can't be opened with a coat hanger as well:

[http://lifehacker.com/5549366/how-to-unlock-your-garage- door...](http://lifehacker.com/5549366/how-to-unlock-your-garage-door-from- the-outside-and-how-to-prevent-it)

Also most of your door locks can probably be opened in a few seconds with the right tools+experience:

[http://en.wikipedia.org/wiki/Lock_bumping#Use_by_criminals](http://en.wikipedia.org/wiki/Lock_bumping#Use_by_criminals)

[http://www.carkeywholesale.com/wholesale/new-cordless- electr...](http://www.carkeywholesale.com/wholesale/new-cordless-electric- pick-gun.html)

Of course someone could always just throw a brick through a window.

<comment><USER6> Exactly like computer security, it's not about making it impossible to gain entrance[1], it's about making it both inconvenient _enough_ and require _enough_ skill that it takes longer or is more noticeable, making it more likely the intruder will be noticed, thus raising the likelihood they will be caught.

That said, a few seconds is a pretty low bar. Commodity locks should be better than this, for all our sakes.

1: This applies to anything where _someone_ has access. It's trivial to come up with ways to secure things that need no ingress/egress whatsoever.

<comment><USER7> While locks don't keep skilled criminals out, you'd be shocked how many unskilled ones there are. Meth/crackheads routinely go around twisting doorknobs in apartment complexes or pulling on car handles just hoping to find something unlocked so they can steal whatever is there. They (usually) don't break and enter, but if they happen upon an unlocked door they'll walk in and steal anything.

<comment><USER8> Not that this is a common attack, but to add to the stew - I knew a guy who left his leather jacket in his car, which was a soft-top convertable. The jacket thief simply sliced open the top and took the jacket.

These days I just tell people to consider the inside of their car a public place, and never to leave anything in there that you wouldn't leave lying on your front fence or similar. There are simply too many ways for people to get into cars to win that game, and ultimately, few things will stop a thief who's willing to damage the car (hammer through a window, or knife through a soft- top, for example).

<comment><USER9> A car is like a glass vault on wheels. That's at least two weaknesses right there.

</comment></comment></comment></comment></comment><comment><USER10> The Wikipedia article doesn't mention this, but the de Bruijn sequence can be computed greedily.

Start with 000...0, keep appending the largest digit possible that doesn't produce a code that's already been used and you'll go through all the codes.

</comment><comment><USER11> "but most of all, samy is my hero"

Context - [http://en.wikipedia.org/wiki/Samy_(computer_worm)](http://en.wikipedia.org/wiki/Samy_\(computer_worm\))

</comment><comment><USER12> The "De Bruijn sequence". I was wondering what that was called, since I realized it's optimal for creating IFS fractals. I figured it must have a name. Yay!

</comment><comment><USER13> Which should I consider more insecure: my garage door, or the deadbolt on my front door? I wonder how commonly lock picking is used in crimes. I've picked a lock before myself, but I have no real idea how effective locks are in stopping people that want to commit house thefts.

I expect an automated garage door opener is much easier to use than a lock pick though, and probably easier to produce and distribute than lock picks. So I shouldn't consider garages as secure.

<comment><USER14> My parents did the thing where they put keyed deadbolts on all of the doors. So when someone wanted to break in they broke the glass on the door, discovered the deadbolt, broke the glass on another door and discovered the deadbolt, then broke the glass on a third door before yet again being foiled by the deadbolt. Then they broke a window and stole our stuff anyway. Apparently they were professional thieves too, since they were hitting half a dozen houses each day while driving through the state. The cops finally caught them when they were pulled over for driving on expired tags or something stupid. They had robbed over 100 homes in two weeks before they were caught.

The only thing the deadbolts did was to make us replace three extra windows.

<comment><USER15> It reminds me of a friend that never lock his very old car so that no-one will break a window to see if there is something to steal inside.

<comment><USER16> About 15 years ago, my aunt stopped locking her convertible. She used to, but people would slit the closed top to reach in and unlock the door to look for CDs and such to steal. A few hundred bucks to replace the top was way worse than losing some change and such. Then she switched to a late 90's Miata which had a lockable center storage bin/arm rest.

<comment><USER17> A relative of mine had to do the same. He's considering sticking those scary spring snakes in the center console as retribution.

</comment></comment></comment></comment></comment><comment><USER18> Time to enable two-factor authentication on my garage.

</comment><comment><USER19> Very interesting. I used to work with an older gentlemen who did RF comms in the military and back in early 2000s he used to tell me stories about his random RF hacking. One such story was around a garage door opener he modified with a potentiometer so he could test opening frequencies by rotating the dial. Obviously this wouldn't work for the "newer" style openers.

I've recently purchased a HackRF to start to learn about RF technologies in consumer grade "security" products like garage door openers, Z-Wave, wireless home security systems, etc. I've realized that after watching the first (very well done) video by Michael Ossman on HackRF that it's not going to be something easy to learn overnight.

While I'm sure this would be "easy" to do with HackRF given what I've read on Samy's site, does anyone have any input on how/why using this recycled hardware would be better in some regard?

<comment><USER20> Hi windexh8er, I choose this hardware because it's portable and convenient. It would technically be much easier to carry out this attack with something like rfcat via yardstick one, hackrf, etc, but I didn't want a USB based device and no need to build my own device when something existed with everything I needed! And did I mention it's pink?

<comment><USER19> Oh, don't get me wrong - I think it's awesome you're recycling and embrace pink. Thanks for the insight though and, well, I partially answered my question because the 8th video Ossmann actually walks through all of this on HackRF...

[http://greatscottgadgets.com/sdr/8/](http://greatscottgadgets.com/sdr/8/)

</comment></comment></comment><comment><USER21> Can't one just sniff the code from the airwaves with a GNU radio RF scanner? Not that it is as cool as brute forcing it in 8 seconds but in someways it seems simpler and more universal.

</comment><comment><USER13> Project idea: use a Raspberry Pi to control your garage door opener, and a battery powered microcontroller in a remote to use a challenge-response scheme to open a garage door.

</comment><comment><USER22> I created a very similar device when I was 17. Back then though, most people with openers had analog remotes. This was one of the first times in my life I ever used (and subsequently purchased) a frequency counter. Oh, what excellent memories.

</comment><comment><USER23> That De Bruijn sequence is highly similar to the way DNA codons can be read.

</comment><comment><USER24> Are there any arduino-based garage door brute forcing projects?

</comment><comment><USER25> The classification markings (U) are a nice touch :)

</comment><comment><USER26> Might as well post a more direct link: [http://samy.pl/opensesame/](http://samy.pl/opensesame/)

<comment><USER27> The "source code" of [http://samy.pl](http://samy.pl) is quite interesting

        /*
        No source for you!
        *//
        /.source.replace(/.{7}/g,function(w){document.write(String.fromCharCode(parseInt(w.replace(/ /g,'0').replace(/	/g,'1'),2)))});

<comment><USER28> Nazi...

<comment> the-dude This is a reference to 'The Soup Nazi' ( Seinfeld )

No soup for you!

<comment><USER28> Thanks Dude.

<comment><USER27> His name is Lebowski!

<comment><USER29> Say what you will about the tenets of National Soup-cialism, at least it's an _ethos_.</comment></comment></comment></comment></comment></comment></comment>


Adding GIT SHAs to your application's HTTP headers - <AUTHOR> http://blog.andrewvc.com/making-life-easier-with-git-shas-in-your-http

<comment><USER2> Using a header isn't quite right. Just implement an URL on your app at /_revision that grabs the HEAD commit. Then write a git-diff-prod command like this:

      #!/bin/sh
      git-diff `curl -s "http://www.yourapp.com/_revision"`

Get your paths squared away, chmod +x it, then type in:

      git diff-prod

And boom! Instant diff with head in production.

Of course, you might want to get your deploy scripts squared away for figure out why your servers aren't restarting if thats the reason for this.

<comment><AUTHOR> Yeah, that was the original reason I implemented it (since fixed), but I just found having it live was too useful to take away.

</comment></comment><comment><USER3> While it's a neat little trick, I'm not so sure I like this. This is adding unnecessary headers and traffic overhead. It doesn't even addresses some of the points the author mentioned e.g. "someone deployed something in a weird way and bypassed the normal deployment process" (if somebody is doing this you have bigger problems anyway). If you are managing your releases in a sensible and automated way then you will also typically have an easy way to check which version is currently deployed or running which doesn't involve adding more baggage to the HTTP headers.

<comment><AUTHOR> True, but I'm not worried about the extra bytes of an HTTP header.

It's actually really useful when coupled with Rails+Unicorn w/ downtimeless deploy. Every once in a while unicorn will run a deploy but stop picking up code changes, and this is a good way to verify that your deploy didn't go all the way through.

Additionally, it integrates with shell scripts easier than most other solutions. Lastly, if you really want you don't need to make it an HTTP header, you can just make a special /git_sha page that renders it out if you're really worried.

Additionally, GIT_SHAs are good for cache busting in some situations (though totally inappropriate for others).

<comment><USER4> That's a really good point. Doing this will invalidate browser cache on most sites whenever you do a deployment. If you are the type that does production deployments throughout the day, then this could slow down the user experience. However, maybe you want an easy-to-use javascript cache reset tool for every deployment.

</comment></comment></comment><comment><USER5> Neat, but kinda overkill to send it on every request. If you're doing Rails (as the article is), try out pig ( <https://github.com/bendyworks/pig> ) and go to /revision on your site.

does not work with heroku since they strip the .git folder... we should probably add that to the readme

</comment><comment><USER6> You know, the other day I was lamenting the sorry state that is caching on the web. I decided a pretty good protocol would be similar to this: make a standard http header that includes a SHA of the content for that url. That way if the content changes the SHA changes, and you get really good cache-ability without the worries of content timeout etc[1]. Further, cache control pragmas/headers/etc don't accidentally get misconfigured in a bad way. Caches just send a header request upstream and if the header hasn't changed, just blast the content on the presumably faster/cheaper local link.

[1] They could still exist for hints or what not, but I presume reasonably advanced caches will be able to heuristically figure out how long the content lasts and do things like start sending results while waiting on the header to return... with some sort of reset if it turns out to be a bad cached result.

<comment><USER7> Are you describing <http://en.wikipedia.org/wiki/HTTP_ETag> or something different?

<comment><USER6> Apparently ETag, but you know, with people actually using it, and a standardized hashing mechanism (to reduce duplication of common elements across sites).

(honestly I had never even heard of it before just now).

<comment><USER8> ommon elements are shared by using a single source (e.g. google's CDN for javascripts) but standardizing makes little sense imvho. For one, you can use an ETag without generating the page and hashing it if it only depends on a db- stored resource, and that is mightily application dependent.

<comment><USER6> 1) What does a CDN have to do with the simple real-world fact that content gets duplicated around sites all the time, particularly stupid crap like funny picture memes? A good global hash of this would certainly help optimize web- caching.

2) A well designed app will hopefully not have every page rendered dynamically at the server anymore, but just have an api to send data back to the page for rendering client side. This benefits from content caching (provided the content is big enough to benefit from caching rather than retransmission).

3\. Using something like varnish in front of your site will allow you to dynamically invalidate the hash when needed, and in the interim, a generated result to a url is no different than a static one.

<comment><USER8> 1) that common stuff reused as-is (such as jquery) can be cached and reused by many, funny picture memes are usually resized, cropped, modified and I frankly do not see many of them, but I load jquery 200 times a day, it seems to me you want to optimize a non-bottleneck.

2) how do you send such content? suppose it's in the db, you need to convert it to a wire format (json or whatever) and then generate an hash for it, but you do not need to, you could just send a revision id as ETag without even reading the full data from the db

3) whatever you want to do with an hash, you can do using an hash as the etag. The latter is simply more generic

<comment><USER6> 1) You are doing browser level cache optimization and bike-shedding, I am looking at it from an ISP level. Once you have a big pipe and many users, things like this actually start to have a noticeable effect on bandwidth usage. Further, no matter what your use case, it has almost no bearing on the normal (statistically normal no digressions please) use case.

2) So I see what you are saying, but you are wrong -- the ETag still requires a lookup of "did content change since then, based on this tag". My system does not preclude a similar mapping of (tag value, last change) in the server.

3) Yeah, I know, my point is that a standardized hashing method for the ETag provides benefits on top of the ETag. Sometimes everyone playing nicely together actually works out better than lots of flexibility.

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> Sounds useful for early deployment stages, but later on you really should tag the code you deploy and perhaps include the tag in your application headers (or in the page footer, or somewhere). And even better, build packages after tagging in your VCS, which gives you numerous advantages, like being able to quickly check if someone modified the code in-place on the production machine.

</comment><comment><USER10> So you have git installed in production?

<comment><USER11> I bet he has "ls" also. The question is, "what's your point"?

<comment><USER12> If it is not necessary, don't install it. Rsync or scp is probably "good enough" for production.

<comment><USER11> Apparently not if you want to include the git commit id in your HTTP headers :)

</comment></comment></comment></comment><comment><USER13> Awesome. A real hack. Beautiful, simple, useful.</comment>


London plans to build real cloud - <AUTHOR> http://news.bbc.co.uk/1/hi/technology/8350770.stm

<comment><USER2> Looks like an exciting project. I like the idea that I could donate money toward this.

</comment><comment><USER3> I especially like this idea: %q{The structure would also be used to harvest all the energy it produces according to Professor Ratti. "It would be a zero power cloud," he said.} #thumbsup</comment>


Facebook's 21-Year-Old Wunderkind Sayman Leaves for Google - <AUTHOR> https://www.bloomberg.com/news/articles/2017-08-28/facebook-s-21-year-old-wunderkind-sayman-leaves-for-google <comment><AUTHOR> Did this guy have to solve algorithm puzzles on a whiteboard?

<comment><USER2> We know the answer to that.

The more interesting question is could he?

If he randomly interviewed as a stranger 20 times, how often would he have been hired?</comment></comment>


MacBook Pro 15" Retina Display Late 2013 Teardown - <AUTHOR> http://www.ifixit.com/Teardown/MacBook+Pro+15-Inch+Retina+Display+Late+2013+Teardown/18696/1 <comment><USER3> I get that repairability is their shtick and all, but I dislike the way they present it without any reference to the underlying engineering tradeoffs. E.g. they kvetch constantly about laminated LCD's, but I'd never buy a machine without a laminated LCD it this price point. Getting rid of the air gap does huge things for contrast and clarity. Also, they fail to distinguish between compromises to repairability that do or do not carry their weight. E.g. the Chromebook Pixel is similar in size to the rMBP, but the rMBP fits a substantially bigger battery (74 Whr versus 59 Whr).

Also, Apple will replace your battery for $99 (iPad), $130 (MBA), or $200 (rMBP). Lenovo charges $150 for a replacement battery for the X220. If you replace the battery midway through a 4-year service life of the machine, how much is the non-repairability costing you? $100 over four years?

<comment><USER4> I agree, though not about the battery. There's a world of difference between being able to instantly replace the battery with a spare and not being able to do so and sit on the charger. To me it's the difference between a device made for actually traveling, and a device that you can only use during a commute.

<comment><USER5> To some extent - but if you've got a battery life of 9 hours (rMBP) or up to 14 hours (Air), then the distinction starts to melt away. There can't be that many people who won't have access to power in that timeframe.

</comment></comment></comment><comment><USER6> This is really self serving nonsense. Of course its going to be harder to repair a computer that is made up of fewer and fewer discrete parts - <USER2> batteries bonded to the case means that the case itself is the battery and should be considered the minimal replacement part.

When my volvo died on the freeway, the "fix" was to replace the engine control unit, not some part of that computer.

This would be like complaining that just because you could replace the MMU on a Mac II in 1988, apple screwed you over by using a 68030 with on board MMU.

</comment><comment><USER7> Who cares. I do not care one bit if I can replace or repair my MacBook or MacBook Air. You know what I care about - the fact that it is very light and I can use it on the flight from San Francisco to Tokyo. Everyone that cares really need to get over themselves. Welcome to the world of solid state. Heck, if it made them more reliable and run longer they could fill the inside with gel for all I care. I buy this because it works and when it does not Apple fixes it. Just to be clear I no longer fix or repair my:

1\. car 2\. LCD TV 3\. stereo 4\. every other piece of electronics made after 2006 or so

They are just to complex anymore and I just do not care.

<comment><USER8> I wish my country had enough capitalism to live like that - its not the reality yet, though.

</comment></comment><comment><USER9> "The proprietary SSD has changed to a PCIe format, but still isn't a standard 2.5" drive."

Still? It never will be because Apple tries to make MacBooks as small as possible.

<comment><USER10> mSATA is an industry standard and very small. But I think SATA could be a bottleneck which is why they moved to PCIe

<comment><USER9> What I mean is that they will try to print bare chips on their own motherboard to save space and weight. They can afford ordering custom chips without industry standard enclosure in volume - why not do that if it saves space.

</comment></comment></comment><comment><USER11> This is what's stopping me from upgrading. Right now I have a non retina display with an ssd and an HDD in the optical drive spot. Im about to upgrade my RAM to 16gb so I can run my windows VM with more than enough RAM.

I like to upgrade the internals without paying an arm and a leg. You can almost upgrade your ram and ssd for what apple charges to go from 8-16gb of RAM.

<comment><USER12> I have the same setup with my 15" MBP, that was probably the last upgradeable Apple laptop ever.

I'd love a retina display, but I'll be holding on to that outdated MBP for as long as I can. I don't really care for the reduction in thickness and weight these mono-block designs have purportedly made possible. It's not even about them overcharging me for parts I can easily upgrade myself for half the price, although they do.

For me the main problem is the fact that as these machines are mere appliances now, their capabilities are fixed from the moment of purchase. There is no way to upgrade RAM, or to replace a damaged part. Now, any kind of defect means the device is bricked. And I will never be able to extend it beyond its original functionality.

This is _not_ OK for a device that costs € 3000+ and has an expected service life of 2-3 years. These devices are simply too expensive for a design that treats them as mere disposables. Because that's what they have become.

If those tightly-integrated hunks of plastic were getting cheaper, I'd say this is just the way things go: a rapid buy-and-replace cycle with a solid recycling process behind it. But that's not the direction Apple is going. They seem to be focusing on customers for whom a frequent multi-thousand dollar expense is no issue.

Increasingly, I just get the sense that Apple is screwing me and the profit margin on those devices is a good indicator for that.

<comment><USER11> They are turning their product lines into ipad/iphone like, they are not upgradable. Even a broken iPhone 5 front glass screen requires a whole new panel.

I am horrified to think what will happen if I get a new rMBP and a year later something breaks. I dont buy apple care, so will I be stuck paying 1,000 for a whole new logic board because all the pieces are soldered on?

</comment></comment></comment><comment><USER13> Realistically, you can only blame them for glued in battery and and soldered in RAM. But then, RAM upgrade is an (overpriced) option. And it's not like there are number of options to upgrade to 32 or 64 GB.

The score is arbitrary value, which is dictated by the market. And we all pretty well know what the market is like.

</comment><comment><USER14> Separate ARM SOC in Apple laptops always puzzled me. Does anyone know why it's there?

<comment><USER15> Which component? I imagine these are for all of the little things that need GPIO, like power and under-keyboard lights, the lid close sensor, etc. There's no use powering up the main CPU to slowly strobe the power light at you when you can offload that to a component that sips power.

<comment><USER14> >Which component?

Cypress Semiconductor CY8C24794-24LTXI Programmable System-on-Chip

<comment><USER15> If you look at the datasheet for that component[1] you'll see that it's actually a really slow (24MHz) "M8C" core, which turns out to be a MIPS core[2]. It's got a ton of GPIO and various other interfaces (I2C, SPI, serial) as well as USB. I would bet that that chip drives a bunch of the little stuff.

[1]: [http://www.cypress.com/?mpn=CY8C24794-24LTXI](http://www.cypress.com/?mpn=CY8C24794-24LTXI)

[2]: [http://eessential.blogspot.com/2010/11/survey-of- microcontro...](http://eessential.blogspot.com/2010/11/survey-of- microcontroller-cpu-core.html)

</comment></comment></comment></comment><comment><USER16> Article seems to imply that there is no way to replace the headphone jack because it's soldered to the pcb, but presumably someone with the right equipment could unsolder it and put a new one on?

<comment><USER5> I'm also a bit confused by that. Surely headphone jacks are _usually_ soldered?

<comment><USER17> On a lot of laptops, the jack is mounted to the case with a single screw and connected to the motherboard via a short pigtail connector. This eases in repair since you can very easily swap in a new connector without having to do any desoldering.

<comment><USER5> That's pretty clever - I'd never noticed, despite having been in the guts of a number of machines over the years.

</comment></comment></comment></comment><comment><USER18> Does anyone else read these just for the awesome pictures?

<comment><USER9> I do. Their comments about repairability sound very ancient.

</comment></comment><comment><USER19> Since they're making it harder and harder to do any repairs or upgrades yourself, I don't think I'd buy a Mac laptop without AppleCare. For iPad/iPhone, AppleCare+ may or may not be a good deal (I'm more likely to upgrade in a year, and have amex coverage on some damage, and think theft is more likely than damage due to using a case, so unclear). I'd probably get it for a Mac Pro, but maybe not for a personal-use Mini.

The problem is the useful life for an iPad/iPhone is usually more like 2-3y, vs. 1-2y, and for a computer, maybe even up to 5y vs. 3y. I guess if it breaks after AppleCare, as long as you have backups, you just buy a replacement early. I miss the 5y service contracts with onsite service from IBM, though (and even _better_ than Apple for take-in service in non-US countries; there aren't Apple Stores in every country, but there were IBM ThinkPad service locations essentially everywhere).

The loophole where you used to be able to buy valid applecare certs for about half price on eBay seems to have closed, so now they're only 20-30% cheaper than Apple.

<comment><USER20> As a general observation on extended warranty programs (without claiming this is the case for Apple, I have no idea), it might not be uncommon to time the program length shy of the expected breakage time of the device. To look at it from another perspective the companies providing them need to make money out of the extended warranty services after all

</comment></comment><comment><USER21> Bring back the matte display!

<comment><USER3> Yes, take my high-resolution laminated LCD and put a film over it to make everything grainy: [http://hardforum.com/showthread.php?t=1744879](http://hardforum.com/showthread.php?t=1744879).

<comment><USER22> Depends what you use your screen for I suppose.

I guess shiny displays and vibrant colours make sense for watching movies and the like. For working however I'm more than willing to trade sharpness for comfort.

I mean, from your link, look at this: [http://i119.photobucket.com/albums/o139/callsign_vega/PICT00...](http://i119.photobucket.com/albums/o139/callsign_vega/PICT00082.jpg)

Which side of the screens looks best for coding honestly?

<comment><USER3> I don't know what's "comfortable" about staring at text through a cheese cloth all day. I find the graininess to be fatiguing. The best setup is a non-matte display with good anti-glare coating and good room lighting.

The best display I've seen for coding is probably the one on the Surface Pro, which is optically bonded to further increase clarity and reduce reflections. I haven't spent much time with an rMBP though.

</comment></comment></comment></comment><comment><USER23> They show a single heatsink because this is the first 15" retina model without a discrete GPU.

However, the high-end model also has a GT 750M, so would presumably be almost identical to the previous model.

</comment><comment><USER24> MBP has a newer Thunderbolt 2 compare with iMac, and iMac will not see an upgrade until next spring. So the notebook is more powerful than desktop in this respect.

<comment><USER25> This has often been true for the Powerbook/Macbook Pro line vs. an iMac.

</comment></comment><comment><USER26> Hmmm maybe I had better pay the extra for the AppleCare.

</comment><comment><USER27> Just when you thought they could not make their hardware any more repair unfriendly, they find a way.

I think iFixit needs to start having a minus score on the repairability score - this can earn a one, it surely has to lose that for extra soldered and glued parts alone.

<comment><USER28> Compare it to the user serviceability of a 1950s muscle car versus a 2013 Tesla.

They're not making it one piece to say "screw you, HN user who wants after market RAM!" \-- they're doing it because it makes the machine physically smaller and lighter.

If you don't like their new work, you can still go to HP and buy a laptop with a DVD drive, a bluray drive, two VGA ports, a PS/2 port, and a proprietary six inch wide docking station port.

<comment><USER29> Things like proprietary screws are there to make the machine smaller and lighter?

<comment><USER28> Well, iFixit says even _trying_ to remove most things from inside the machine has a chance at breaking other parts irreparably (e.g. removing the battery (which takes 30 minutes of practice) has a good chance at slicing your trackpad I/O cable).

The user hostile screws are just trying to say "Look, we're trying to save you from yourself. There's nothing in here you can fix without ripping cables and rendering your machine into an ineffective boat anchor."

<comment><USER30> I bought a new ThinkPad W530 back in May along with an SSD and 4x8GB sticks of RAM to upgrade myself. I spent five minutes looking over the service manual and another five minutes doing the upgrades, thanks to the standard screws that Lenovo chose to use.

When I bought my last MBP, I had them (at the Apple Store) upgrade the RAM, which meant I had to wait around for 90 minutes for them to do it.

<comment><USER31> To be fair, changing RAM and putting in an SSD in a unibody MBP would only take a few minutes if you did it yourself too. The only "tricky" piece was disconnecting the battery (not strictly necessary), and that only needed a triwing screwdriver.

</comment></comment></comment></comment></comment></comment><comment><USER32> well shit. Cannot upgrade anything =(</comment>


A few words with Jack Tramiel & the Commodore 64 gang - <AUTHOR> http://blogs.mercurynews.com/aei/2007/12/20/a_few_words_with_jack_tramiel_and_the_commodore_64_gang/

<comment><USER2> "the Amiga ... missed on graphics and so never really attracted game developers to its platform."

I don't know about the US, but in Europe the Amiga epitomized games and multimedia development for a decade since the mid eighties (the demo scene was huge in those days).

Also, it was light years ahead of it's time on the graphics/multimedia front.

<comment><USER3> Yeah, that was a strange quote. The article then contradicts itself a paragraph or two later.

</comment></comment><comment><USER4> Anyone else have a Commodore64? This was _my_ first computer, since my parents got a newer PC leaving me with the Commodore. All I can remember was playing Skater Or Die.

</comment><comment><AUTHOR> In another post someone asked who Jack Tramiel is ~ <http://news.ycombinator.com/item?id=419249>

</comment><comment><USER5> Also, the designer of the C64's SID chip, Bob Yannes, co-founded Ensoniq, which is a very cool synth/sampler company.</comment>


Sinfonia: A New Paradigm for Distributed Systems - <AUTHOR> http://www.systemswemake.com/papers/sinfonia

<comment><USER2> Here is a summary of the Sinfonia paper. <http://news.ycombinator.com/item?id=2294378>

[http://muratbuffalo.blogspot.com/2011/03/sinfonia-new- paradi...](http://muratbuffalo.blogspot.com/2011/03/sinfonia-new-paradigm-for- building.html)

</comment><comment><USER3> Is there any source code available any where? (I only skimmed the paper.)

</comment><comment><USER4> Discussion in the other HN thread: <http://news.ycombinator.com/item?id=2294378>

<comment><USER5> Isn't your reply there the only reply on that thread? And doesn't it just link here?

Are you a bot or something?

<comment><USER4> I was just being silly. I was hoping for an infinite loop of clicks....</comment></comment></comment>


Test-dicking the force-feedback vagina with William Gibson (1993) - <AUTHOR> https://archive.org/details/Future.Sex.Issue.04/page/n23 <comment><USER2> That was one of the more surreal things I've read in a while. Every time I read Gibson's works I'm struck by how different our present is from his imagined near-future, but simultaneously how similar.

We have crushing government oppression, staggering wealth inequality, corporations that ignore laws at will, media personalities running the country (literally, in some places), and the internet: once hailed as the great equalizer, now the opiate of the masses.

We're living in a cyberpunk dystopia.</comment>


No to SQL? Anti-database movement gains steam  - <AUTHOR> http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9135086 <comment><USER2> _Cassandra can write 50GB of data in 0.12 milliseconds, more than 2,500 times faster than MySQL._

Really? Cassandra can write 416TB, 666GB per second? If Cassandra can write 50GB in 0.12ms, then it can write over 416TB in a second and 25petabytes per minute. Which clearly isn't true. Of course, that quote would also mean that MySQL can save 166GB per second.

The article is a piece about technology that the writer doesn't understand. They all have trade-offs. Key-value stores eliminate your ability to access data by anything other than its key. So, you have an article with an id of 5. What if you want to look up the articles by author 9? You're just unable. Column based databases aren't magic either. They just change the orientation of the data. Rather than seeing 1,Adam,West;2,Mark,Twain;3,Will,Smith you see 1,2,3;Adam,Mark,Will;West,Twain,Smith. That offers some advantages - such as being able to do metrics on a column easily - but it also means that if you want to get the data for one row, it has to do MORE work than a regular row- based database. To retrieve 1,Adam,West it has to do multiple lookups since the data isn't located next to each other. And frankly, random access of a row is what you're likely to want.

 _They run on clusters of cheap PC servers. PC clusters can be easily and cheaply expanded without the complexity and cost of "sharding," which involves cutting up databases into multiple tables to run on large clusters or grids._

That's like saying that if you plant a hamburger you'll get a McDonalds. They don't just magically run on clusters of cheap PCs. The fact is that there are tradeoffs. If you put 50% of the data on server1 and 50% on server2 you'll get faster query speeds except that you then have to know where to look for a specific piece of data.

So, sharding: basically, you split your data along logical (or non-logical) lines into separate databases. Like registration at a conference, users A-M are in DB1 and users N-Z are in DB2. So, when someone comes up with a query, you can easily tell which place to send them and then the query is run there. Or you can non-logically split and have a map that tells you where to go. So you query metadb and ask "where's Frank" and it says "Frank is in DB1" and then you query DB1 for Frank.

BigTable isn't so different. It does do some awesome auto-splitting of tables, but when it comes down to it, it's much the same. There's a single META0 tablet that gets queried to find the location of the META1 tablet which knows the location of the actual data. And, in order not to overload the META0 tablet, one needs to cache the location that you get back.

\--

Often times, the problem is that you have web programmers who wouldn't know a B-Tree from a linked list. All of these technologies exist because there are certain things that they're good at. However, what this article purports to know is that these NoSQL databases are just superior. In most ways, they're inferior. A key-value store has its place, but it's severely limiting in a way that you can't _just_ use a key-value store; you need more querying power. Likewise, whether a column-oriented database is right for you depends more on how you want to access the data (by column or by row).

Oh, and really, learn SQL indexing and check whether your queries are doing full table scans. That's the root of a lot of problems. I mean, a good index should do lookups in log(n) time which means that on 10,000 rows a query should take 1/769th the time; on a million rows a query should take 1/50,000th the time; on a billion rows it will take 1/33,333,333th the time of doing a full table scan of a table that size. Yeah, indexes make a huge difference, but they aren't magic either. They merely order the data in a certain way that makes it easy to pluck out certain rows since you don't have to look at every value. For example, dictionaries are alphabetized and so you don't have to look at every word. You just start jumping toward the area of the word you're looking for. Indicies work the same way. Now imagine if the dictionary was unordered. You'd have to look at every single word to see if it was the word you were looking for.

Oh, and just saying "put an index on stuff" isn't enough to know. It isn't too complicated, but there's a Google talk that goes over some of the mistakes one can make with assuming that indexes are doing what you want ([http://www.youtube.com/watch?v=u70mkgDnDdU&feature=chann...](http://www.youtube.com/watch?v=u70mkgDnDdU&feature=channel_page)). It's in the middle somewhere, but it's a good watch for the whole thing.

\--

Really, is this the type of article we've become? I mean, column-oriented datastores and key-value datastores are both valuable technologies, but a NoSQL flame written by someone who doesn't know that Facebook is still MySQL backed and uses Cassandra for only specific things and that they use many different technologies where they're good (like heavy use of memcached as a key-value store to reduce load on MySQL where queries aren't needed). Or perhaps that the article doesn't seem to acknowledge the drawbacks that the authors of these systems would talk about. For example, mongoDB states that they lack ACID integrity and that it's more suited for "High volume, low value data" - that should be read as whether someone has upvoted or not; if that data gets lost it doesn't really matter so much because the person can click the vote button again and all is well or just because it isn't super important data.

Why are we supporting "we hate this technology just because"? Technologies are tools that have their places. It's foolish to write off a good technology just because you want to make fun of it or deride it. Use the right tool for the job. In your web application, you might find that using multiple tools in concert is the way to go.

<comment><USER3> "They all have trade-offs. Key-value stores eliminate your ability to access data by anything other than its key. So, you have an article with an id of 5. What if you want to look up the articles by author 9? "

For cases like that you don't have one source of data, you do almost like an AFTER INSERT trigger to update other flattened tables of data that you need.

For instance, where you would normally perform a JOIN you would just after save update a JOIN table or a VIEW that is created by incremental updates.

So then you could filter by many other things and really aren't limited too much by space to make those duplications.

It happens with large RDBMS systems anyways after about 5GB of data, same type of scalability decisions have to be made.

But yes the article is off and you are right, most likely systems will approach this with multiple solutions for specific problems.

<comment><USER4> _It happens with large RDBMS systems anyways after about 5GB of data, same type of scalability decisions have to be made._

More like 5Tb these days.

<comment><USER3> I should have clarified, I meant around 5GB per one type of data. Maybe a table or dataset that needs to be merged. For instance if you had a product database table that needed to be joined with another GB large or set of data at runtime.

At that point, even in RDBMS you have to stop with the joins and flatten. I have experienced these limits in Oracle and MSSQL around 20-30 million row tables.

Scalable fundamentals like database flattening, dimensional modeling etc are all what key value stores give you from the start. But really a good mix works best or project specific, just saying in the future with TB, PB of data the JOIN is a historic remnant.

It is possible one day that RDBMS will be seen as one of those evil optimizations that we made in our small relative worlds at the time.

<comment><USER4> I've tables much, much larger than that.

 _It is possible one day that RDBMS will be seen as one of those evil optimizations that we made in our small relative worlds at the time._

I doubt that for the simple reason that relational databases are maths: the relational algebra and relational calculus. There's no such theoretical underpinning to object databases.

<comment><USER3> _I doubt that for the simple reason that relational databases are maths: the relational algebra and relational calculus. There's no such theoretical underpinning to object databases._

True, the relational architecture is moved to the object or code level, if you think about it in relation to size, it makes more sense there for the future.

The RDBMS was the brain but it is also the storage, code will now dictate how to use the storage and not the storage itself, the storage is becoming a component.

</comment></comment></comment></comment></comment></comment><comment><USER5> This movement sounds reactionary, and perhaps for good reason. SQL has been the default method for storing and retrieving data for a long time, but obviously it isn't the best fit for every case.

That said, I like sql. I find it extremely easy and natural to keep relational models in my head and write queries. While I do appreciate some of the tools that free me from writing very basic CRUD stuff or persisting objects, I don't like to be too insulated from my database, and I'll gladly drop to sql when I need to.

The problem is that sql has been used for _all_ data persistence and retrieval for far too long, when all kinds of different models might have been appropriate. So I guess this is a kind of backlash. And eventually, there will be a backlash against the backlash - or, more likely, people will forget there ever was an argument, and we'll get a new generation of developers who think they've discovered relational algebra for the first time.

<comment><USER6> Another thing is that some people have problems with SQL itself, not relational databases per se. SQL is just the compromise-of-a-standard that came out of several RDBMS query languages competing for mindshare.

And, naturally, in some peoples' minds any problems that MySQL has are joined to SQL, and in fact all relational databases.

</comment></comment><comment><USER7> There seem to be two quite contradictory arguments for NoSQL. One camp says, we already have what we need in the form of [programming language] objects, so why would we take everything apart and map it to something as reductionist as relational tables?

The other camp says, relational tables are soooo complicated, we need something even more reductionist and free form, so key-value pairs are just right.

I can understand the second argument, but the first is a step backwards unless your programming language is something like lisp, which has a reductionist data model itself.

Object oriented models are fine if you write one application. But they tie functionality to data very closely and that makes repurposing of data for seperate applications much more difficult. So how do they analyse their data or use it in more than one application?

They have to write a lot of code using an application specific object oriented API instead of a general purpose reductionist data model. That's horrible but how horrible it is only shows a few years down the road. It's a disaster in the making. A whole army of programmers will be required to extract data from all those big APIs of legacy apps.

I'm convinced that data has a different life cycle than procedural code and therefore needs to be expressed in a simple, uniform, reductionist model independent of all application code.

<comment><USER8> "Object oriented models are fine if you write one application. But they tie functionality to data very closely and that makes repurposing of data for seperate applications much more difficult. So how do they analyse their data or use it in more than one application?"

This was an extremely poorly-written and poorly-researched article. One problem is that the projects being discussed are not object databases in the sense of storing straight-up serialized representations of business objects.

Take CouchDB for example; the basic "thing" you store in it and get back from it is a JSON object, which is a set of key/value pairs. In this sense it's not too far removed from SQL-based DBs, because you still choose which bits of data you're going to store (the keys in the object). It departs from the SQL point of view in not requiring that all the records have the same schema, and in not having a representation (at the data-storage level) of relations between records.

This turns out to offer some big advantages: in my experience, the number-one cause of unwieldy SQL is a schema that's had to grow over time to accomodate ever more edge cases. Maybe it's been done through lots of nullable columns, maybe it's been done through lots of related tables or some other mechanism, but it frequently has to be done and ends up making the database painful to work with.

CouchDB throws that out the window: edge-case records simply go in like anything else, and if they don't have some particular field present in other records, so what? The "query" is actually hitting a map/reduce in which the "map" function can take whatever action it wants with a record that's missing some particular key. It can skip that record, it can spit out a default value for a missing key, it can do anything it likes.

"I'm convinced that data has a different life cycle than procedural code and therefore needs to be expressed in a simple, uniform, reductionist model independent of all application code."

Simple and independent, yes. Reductionist and uniform, no.

To run with CouchDB as the example, those assumptions are thrown out because CouchDB essentially adds a layer to the stack. Traditionally, you have application code over _here_ , querying data over _there_. In CouchDB, you have application code which queries a CouchDB view which returns data, but the query doesn't necessarily know anything at all about what the actual data in the DB is, or how it's structured (or even if it _is_ structured in any sensible way; maybe it's just a bunch of random key/value pairs). The view layer is the part which cares about that.

And views are not static (or mostly static) things like the schemas in relational DBs; views are free to evolve over time, you're free to add or remove views in response to changing needs, and _the underlying data never has to change as a result_. And so you don't need to agonize over the most efficient way to reduce your data to a uniform schema. You don't need to "migrate" your underlying data storage representation to change the types of things you can store or the types of queries you can run.

<comment><USER7> I think data independence all but implies a reductionist data model (uniform probably isn't a very clear term). And when I say data model I don't mean a particular schema but the primitives that are used to model the data, like relations and attributes in the relational model or key value pairs in Berkeley DB.

I cannot say anything useful about CouchDB as I don't know it nearly well enough. What I think doesn't work is to hide data behind a procedural API when it comes to read access (write access is a different matter).

A procedural API is a black box that you cannot reason about and has a very application specific purpose that doesn't lend itself to analytics apps. Analytics apps should know as little as possible about particular applications. They cannot easily call arbitrary functions.

My experience with data centric apps is that it's a good thing to have that situation where everything is a table and each of the few operations you have creates another table. Tables in, tables out. The same thing works with lists, key/value pairs, etc.

My battle cry would be "No applications specific APIs" (for data access)

</comment></comment></comment><comment><USER9> My biggest hold up to investing time learning how to harness "noSQL" data stores is that there are so many young-ish projects and I'm afraid of picking a loser. Couchdb, mongoDB, Redis, TokyoCabinet, etc, etc.

Seems like it's too early to cast lots, and I'll just stick with what I know for the time being. Is that prudent of me or just naive?

<comment><USER10> The noSQL school includes both key/value databases and bonafide object stores. None of this stuff is new, BerkeleyDB, circa 1986, is as industrial strength as they come. O2, GemStone, Statice, etc. all go back to the 70s and 80s.

Just because something is on github doesn't mean it's ground breaking ;-) The future is full of wonderful things that are yet to reach us from Lisp and Smalltalk research of the past.

<comment><USER6> The sticking point with BDB is typically its license - if used commercially, you suddenly need a commercial license from Oracle, and the cost is unspecified.

</comment></comment></comment><comment><USER11> Performance is always a trade-off; wou rarely get something for nothing. These object stores are great when all your doing it storing objects, but that's a pretty simplistic use-case. If you need to do more with your data than simply read it back in object-sized chunks, you're going to find that a relational database probably provides better performance. For web sites especially, retrieving and constructing objects is a fairly expensive operation if you're just generating list pages.

I wonder if we just have a generation of programmers who can't think in SQL. They're used to using ORMs (which are useful abstractions) but can't work at a lower level. Sending a query over the line to get exactly the results you want, and no more, and have it optimized and run entirely on server is pretty damn efficient.

<comment><USER4> _I wonder if we just have a generation of programmers who can't think in SQL._

I think that's probably true. SQL requires thinking declaratively, not imperatively, and in sets, not objects. Kids these days don't understand the difference between a table definition and a class and the difference between a row and an object. The declarative/functional style isn't really taught anymore; everyone just wants to learn Java and get a job.

If anything, ORMs are _less_ "scalable" than SQL because under the hood the system _is_ based on SQL, and in an effort to be completely generic, the ORM generates really bad SQL.

<comment><USER12> Indeed, "kids" (by which I assume you mean "assembly-line CS grads") these days are pretty much using Hibernate, ActiveRecord or (I guess?) LINQ. This is a good thing: The O/R mismatch exists. For good programmers ORMs _are_ more productive in most cases (and you can write raw SQL for the exceptions); bad programmers have _never_ gotten the relational model (and there's plenty of legacy code to prove it.)

However, the discussion about "kids" is a total red herring, because I'm pretty sure all of the people involved in talking up Tokyo Cabinet, memcachedb, Couch etc on one end and Cassandra, Hypertable or HTable on the other are fully aware of the difference between a class and a table. The truly clueless don't even know the discussion is happening.

The object/document database revival circa 2009 is about three things:

A. People are _already_ using object-based access for almost everything, so if they're _not_ using relational features it's trivial to drop in an object store and get better performance/less overhead.

B. On the low-end, sometimes a relational database _is_ too much overhead -- if not in performance, in administration. (SQLite is cheap, sure, but sometimes you _want_ just a disk-backed hash table.)

C. On the high-volume-data-analytics-end, RDBMSs don't perform well enough- unless you shell out serious cash for Oracle or Greenplum, Aster Data, Teradata, etc, and even then they still can't handle the volumes MapReduce and Bigtable-alikes can.

<comment><USER11> A. That is fine until the first time somebody has to write a report.

B. With the right product, administration is easy. MySQL is completely ubiquitous and something like SQL server is easy. This certainly conflicts with point C.

C. Most of these people aren't doing high-volume anything. If you are doing high-volume stuff (like Google) then of course it makes sense to use something very specific to your task. But that doesn't mean Bigtable, for example, makes for a good _generic_ solution.

<comment><USER13> I think the key insight in all this is that the same database you store your objects in... shouldn't be the same one you write reports from. You can have two. One object store for your application, and another analytic DB for your reports.

The complaints about SQL is that is optimized for report writing, not application development. Fine, so split that out.

Which is happening. Which is working.

<comment><USER14> Do you happen to know any articles on people splitting their data across 2 types of storage this way ?

If there is any data that should be stored in 2 separate stores, I can see applications becoming messy rather fast in trying to replicate changes.

Unless of course this is usually done by having a clean separation between which data goes where, but I doubt if any domain can ever really be that easily split up.

<comment><USER13> Well, for starters - most companies don't run reporting queries on their production SQL database. They mirror, summarize, partition, index and cube a separate reporting DB, so that big/mean queries don't cause massive latency on their site/product/production system. Which isn't quite the same as using a different data-store altogether, but some kind of split is commonplace. Which means that some kind of difference between queries/applications in reports/production is already common. They key here though, is that setting up an RDBMS that can handle analytics on even a moderately large data-set is a major task, can be complex/pricey, tends to use big iron, and only scales so far before it gets very, very expensive.

But, yes there are examples of what I just described. In practice, in many problem domains, most data of interest for reports does not change once it is written, so syncing up is not a major issue.

Streamy is a good example, I think. They use HBase for the front end, and run MapReduce jobs on the back end. [http://wiki.apache.org/hadoop- data/attachments/HBase(2f)HBas...](http://wiki.apache.org/hadoop- data/attachments/HBase\(2f\)HBasePresentations/attachments/HBase_Goes_Realtime.pdf) Another presentation is here: [http://www.docstoc.com/docs/2996433/Hadoop-and- HBase-vs-RDBM...](http://www.docstoc.com/docs/2996433/Hadoop-and-HBase-vs- RDBMS) That is Hadoop and Hadoop, which is nice - but HBase is optimized for the front end and is fundamentally different than typical batch operation of Hadoop.

CouchDB sort of takes this approach, albeit with key/value and pre-defined and materialized map/reduce views on the same store. I think this dichotomy will become increasingly common, and will be less cumbersome than it currently is as the tools mature.

Key/Value for the front end and Map/Reduce on the back end makes a lot of sense for a lot of problems, since key/value is how many applications actually work, and there is the added benefit that systems like these scale linearly on commodity hardware using FOSS, can make it cost effective - and much simpler, than scaling a traditional RDBMs as an analytic data-store. The upside to this is too good for these systems not to win a big chunk of the market. And you can have your SQL - albeit on top of MapReduce - in reports, where it belongs :)

</comment></comment></comment></comment></comment></comment></comment><comment><USER15> At the point you see the load drop on the following graph, we switched from MySQL to Redis:

<http://db.lloogg.com/load.dir/load-1month.png>

Alternative DBs are not good for everything, but SQL databases are not good for everything as well...

<comment><USER16> I'm sorry, but this graph says nothing. Load average is meaningless; for example, one process using 100% CPU at all times would show a load of 1.0, and one process that repeatedly spawns threads but uses little cpu can push the load average very high.

What's the difference in maximum number of pages served per second using ab? Or average CPU usage? Or average disk throughput?

I'm not saying I disagree with your conclusion, but this doesn't prove it.

<comment><USER15> got your point actually, you can see all the data here: <http://db.lloogg.com>, there are many stats about load, disk I/O, and so on.

<comment><USER16> That's much more interesting data, but it clearly shows that the reason Redis was performing better is because it's caching a ton of data in memory, whereas MySQL was constantly hitting the disk for access. This seems to be a misconfiguration of either your kernel settings or MySQL settings. If Redis effectively cached your entire dataset in RAM, then MySQL could have done so as well (or the kernel could have). I'm guessing that you configured MySQL in a way that caused the kernel to fight with the database over memory usage.

</comment></comment></comment></comment><comment><USER17> This seems oversimplified to me. When I think "database" I think of ACID properties. You can have SQL without ACID, and you can have ACID properties without SQL.

<comment><USER18> The problem with this simplification os the problem-space is that ACID properties cannot be maintained (see CAP) when you start moving to a distributed model. The "no SQL" group is just using it as a catchy hook upon which to hang their hat, it is not SQL per se but the traditional RDBMS that is reaching its limits, but it was hard to make a memorable name that included "RDBMS" :)

<comment><USER4> _ACID properties cannot be maintained (see CAP) when you start moving to a distributed model._

You need to pop back to the 1960s and tell IBM that before they wrote TPF.

</comment></comment></comment><comment><USER19> I wrote a fairly detailed post about the Death of the Swiss-Army RDBMS on my blog, <http://www.roadtofailure.com> :)

The RDBMS has been used for way too long as a generic "bucket" for any sort of data storage and analytics. As a result, speed and scalability have suffered. With Social Media and the advent of "web-scale" data, engineers need to realize that the storage and analysis solutions they use must be driven by the type of data they're storing, and what they want to do with it.

As I stat, "The ACIDy, Transactional, RDBMS doesn't scale, and it needs to be relegated to the proper dustbin before it does any more damage to engineers trying to write scalable software."

</comment><comment><USER20> Easy in != Easy out ... didn't your mum ever tell you, "there's no such thing as an overnight success"

\---

Personally, I have absolutely no rush in dropping MySQL as a persistent store.

</comment><comment><USER21> As far as I know, HBase is the software that they should point out in the key- value discussion, not Hadoop.

</comment><comment><USER22> This article is the biggest load of fucking bullshit I've ever read. That's all I'm going to say about it. The author couldn't tell his ass from a hole in the ground.

<comment><USER23> I am glad you are getting modded back up from the grave; I agree and appreciate someone calling a spade a spade.

We don't always need to get into thesis-length technical arguments about the merits of so and so viewpoint - sometimes an article is just _bullshit_ and deserves to be dismissed as such.

<comment><USER23> Quite a turnaround. The GP was at -2 when I wrote the above.

HN is a fickle mistress indeed!

</comment></comment></comment><comment><USER24> I'm not convinced. Of course these projects are useful for some applications but most online services will never grow to the size where you HAVE to dump your SQL server for something more scalable. And in the meanwhile SQL is just sooo convenient and easy to develop on. Why would I want to switch unless I have to?

<comment><USER25> > And in the meanwhile SQL is just sooo convenient and easy to develop on.

No, it isn't, it's a pain in the ass because it doesn't match how applications are programmed. I know SQL pretty damn well, and I know how to tune a database very well, and SQL still sucks.

<comment><USER26> It has it's pain points to be sure, but the fact that "it doesn't match how applications are programmed" is because it's modeling data not code. Yes your object store will make the application much easier to write initially. But then what happens when you need reporting or worse, some feature that you never anticipated that requires a different view into the data.

That's not to say SQL is the end-all-be-all, but people are so quick to dismiss it, and I bet there is going to be _a lot_ of pain felt as code based on simpler databases ages.

<comment><USER25> > But then what happens when you need reporting

Then I replicate the applications data out into a relational database for reporting. 99% of what applications need isn't reporting. I want to use many different data structures, not be forced to fake everything with a table, or continually reassemble things from tables.

SQL has its strong points, being a convenient data store for applications isn't one of them.

<comment><USER26> Again, it's not convenient for greenfield, but applications don't spend most of their time in that state. A good ORM is a compromise between holding onto that flexibility and being able to reconstruct your data objects easily.

I realize that there are a lot of applications where you will never need that flexibility and a simpler database would be the right choice. My attitude is based a response to the unbelievable hype surrounding these technologies among a certain class of tech blogger. Given how quick many people seem to be willing to chuck the relational model out the window without acknowledging any of its benefits, I predict there will be a lot of rude awakenings and failed projects in the next 10-20 years.

<comment><USER25> > I predict there will be a lot of rude awakenings and failed projects in the > next 10-20 years.

As opposed to the many many failed or stuck projects out there now because they made the mistake of using a relational database as an integration point between many applications and can't risk changing anything now because that one big global variable (the db) can't be touched without breaking 15 applications.

The relational folk don't like to admit their shortcomings either.

</comment></comment></comment></comment></comment></comment><comment><USER27> No to SQLServer and Oracle. =)</comment>


Ask HN: Downvotes of 'I disagree' comments. - <AUTHOR>

Comments like "I disagree" get downvoted because they don't add value to the discussion. But doesn't the same apply to a downvote without commenting? <comment><USER2> If the comment being downvoted detracts from the discussion, then downvoting it without commenting improves the discussion.

</comment><comment><USER3> If somebody sees an on-topic comment they disagree with, and posts "I disagree" with no further explanation, that's not adding value to the discussion.

If somebody sees an on-topic comment they disagree with, and downvotes it with no further explanation, that's not adding value to the discussion.

If somebody sees an off-topic comment that doesn't add value to the discussion, they should downvote it so that other people won't be distracted by it. Adding a comment saying "I downvoted you because your comment was off- topic" would add even more noise, so don't do that.</comment>