Hacker Newsnew | comments | show | ask | jobs | submit | CoffeeDregs's commentslogin

FYI: 2003 and not 2013


Thanks, we fixed the title.


The Thinkpad X1 Carbon is, hands down, the best Linux laptop (IMO). But it was completely ruined in by the keyboard/mouse in Gen 2. Now that Gen 3 has fixed that, the X1C is king of the hill again.

    Macbook's trackpad
I'm a trackpoint guy, so avoid trackpads...


I think the functional people took a whack at this question with functional, reactive programming. Some links:





EDIT: oops. I just noticed your price range. The X1 Carbon doesn't fit with that.

I would strongly recommend the last generation Lenovo X1 Carbon, but I would strongly recommend against the current X1 Carbon for a few reasons:

- They merged the trackpoint's buttons into the trackpad's and now it's very difficult find the middle chord or to select text using the trackpoint.

- They merged the function keys with the utility keys (e.g. volume control) into a single, dynamic row, so closing a window (Alt-F4) often requires you to toggle from utility to function key. If this sounds confusing and useless, it is.

- Worst, because of the doubled-up row (fn, utility), Esc and ~ wound up overlaid. So they moved the ~ next to the LOWER RIGHT Alt key. I hit Esc every time I try to reference my home directory...

Other than that, it's a lovely laptop.

Oh and don't get a HighDPI display unless you want to deal with funky application layout issues...


agreed, i have a last-gen carbon as my work laptop, and it's wonderful. fairly crappy battery life, but the rest works beautifully and is very pleasant both to carry around and to use.


Yeah, sounds like a pain. But I don't do anything like that and my pan is perfectly functional (and great at browning).

The only thing I really do is to: use it, immediately clean it, put it on the stove to heat and dry, then wipe on a layer of whatever fat I have at hand. Really, the last step is the only difference from how I treat most pans (yes, I dry them with the heat from the stove). I have done the real seasoning thing, but found it both a pain and not noticeably more effective...


Yeah, I just did the same thing. 235711 Unfortunately, it didn't yield anything much more interesting than 1260...


I'm very much for open source and all, and I'd love to see Apple as the bad guy here (since I think they're a Bad Guy), but I'm not sure what is the big deal. AFAICT, every CPU vendor has a libm implementation. Apple wants to be tight-lipped about its hardware. [Maybe] Since hardware reviewers seem to get their information on the hardware from compilers, Apple is removing as much information as practical to avoid competitive information leaking.

It's a bummer to see a reduction in the amount of open source, but their license is fairly clear and I can't say that I blame Apple for trying to keep competitors away. Further, it looks as though most implementations is closed-source-y since the source code is highly tied to CPU idiosyncracies...


Apple's libm license: http://opensource.apple.com/source/Libm/Libm-315/APPLE_LICEN...

Intel: https://software.intel.com/en-us/articles/intel-math-kernel-...

AMD: http://developer.amd.com/tools-and-sdks/cpu-development/libm...

Android: https://android.googlesource.com/platform/bionic/+/master/li... (from FreeBSD?)


> I can't say that I blame Apple for trying to keep competitors away.

I certainly can. They restrict their users freedom to own the machines they buy by disrespecting their customers by giving them software without available source.

You can always blame them. It is not something that is ok, it is ethically wrong to sell someone something without giving them the proverbial floorplan. If it is a "competitive disadvantage" for others to know how your software or hardware works, then you must not have a very compelling product if it cannot stand on its own in the open.


I gotta say that, after not having used it in about 4 years, I love looking at Haskell again.

One question: could CurrentTile.hs be DRYed up? https://github.com/egonSchiele/chips/blob/master/src/Chips/C...

This repeating pattern seems ripe for DRYing:

    checkCurTile (Chip _) = do
      liftIO $ playSound (soundDir ++ "collect_chip.wav") False
      tileAt Current .= (Empty def)
    checkCurTile (Gate _) = do
      liftIO $ playSound (soundDir ++ "door.wav") False
      tileAt Current .= (Empty def)
    checkCurTile (KeyYellow _) = do
      yellowKeyCount += 1
      tileAt Current .= (Empty def)
    checkCurTile (KeyBlue _) = do
      blueKeyCount += 1
      tileAt Current .= (Empty def)


Sorry for bad formatting and not compile checking the code, but this is an improvement imo:

    checkCurTile b = do
      case b of
       Chip -> liftIO $ playSound (soundDir ++ "collect_chip.wav") False
       Gate -> liftIO $ playSound (soundDir ++ "door.wav") False
       (KeyYellow _) -> yellowKeyCount += 1
       (KeyBlue _) -> blueKeyCount += 1
      tileAt Current .= (Empty def)


Ah yeah, it could definitely be refactored. There's some repetitive code in there.


His follow-up is at: http://changelog.complete.org/archives/9241-update-on-the-sy...


I run a rolling distro (Debian Testing) on personal-use machines (laptop; work development desktop; personal server).

I run fixed release distros on production servers/devices. It's important to be able to install a new package on a machine and not have a hundred dependencies need upgrade, break or conflict. And lots of packages are available in backports when you really do need a newer kernel on Wheezy (https://packages.debian.org/wheezy-backports/kernel-image-3....).


> I run fixed release distros on production servers/devices. It's important to be able to install a new package on a machine and not have a hundred dependencies need upgrade, break or conflict.

Isn't that an argument for rolling release? I don't see how this would support using fixed release distros.


Not when you have a few hundred servers. Then, you want consistency. Consistency between servers, between datacenters and between pre-production and production environments.

Now, you can get there with your own repos and a rolling distro. Or you can accept a test/upgrade cycle for a fixed release distro every half year or every year. I personally think the latter is less error prone.


That is what distros like Manjaro / Chakra are effectively. They just pick a date, grab all of Arch, test it for a few weeks, and push it to end users in batches.


I am unfamiliar with Manjaro and Chakra. My experience with Arch is limited to my Cubox-i. It's a nice distro, with an excellent community. I liken it to Gentoo in its glory days.

Having defined my limitation in the observation, I'd just like to point out that, when it comes to distribution stability, for large server deployments, there is safety in numbers. Should a problem occur in a "stable" package, the odds that you are the first one to find the error are smaller with popular server distros (RHEL, Centos, Debian) than with less popular distributions. It's not a statement regarding the intrinsic quality of the distribution. It is a statement regarding the overall quality of the distribution + installed base.

All in all, for a distribution to dislodge entrenched players, for this use case, it will have to be an order of magnitude more stable.


Using a fixed release only requires that you apply the update once every few years, so you can plan for it. You can do it at a quiet time when you are available to fix any problems. With a rolling release you have no idea if something is going to break at an inconvenient time.



Applications are open for YC Summer 2015

Guidelines | FAQ | Support | Lists | Bookmarklet | DMCA | Y Combinator | Apply | Contact