The CODE Keyboard - <AUTHOR> http://www.codinghorror.com/blog/2013/08/the-code-keyboard.html <comment> X-Istence I don't understand what the obsession is with the old IBM Model M type keyboards. I am able to type faster and more accurately on my Apple flat aluminum keyboard that I have ever been able to type on a Model M. On top of that, switching to a flatter keyboard that sits closer to the desk has actually caused any and all pain I used to get while typing to go away.

The other thing is I'd miss the extra function keys I get on my full size Apple keyboard. Specifically F13-F19, which I have bound to a whole bunch of different things that help me throughout my day.

<comment><USER2> I don't understand the fascination with keyboards by software developers. I spend a lot more of my day thinking, testing, navigating code, etc, than I do punching keys. There are a lot of professions where keyboard interaction is critical but I don't think software development is one of them.

<comment><USER3>
      navigating code

I do this with the keyboard (vim)

<comment><USER4> Same in Emacs. I always watch with fascination (and some frustration) when my friends and coworkers use IDEs—Visual Studio and Xcode, mainly. Some navigational tasks are much faster with pointing or gesturing, but many basic tasks require the same context switch between mouse and keyboard, which I can't tolerate.

<comment><USER5> That's not a context switch. Changing to email is a context switch.

Using a mouse, or trackball, or trackpad, is just input. On my laptop, I don't even lift off of home row to 'mouse' \-- I just move my thumb.

At my work desktop, I've got one of those apple wireless keyboards and trackpads and it's actually quite ergonomic, except for the staggered keys.

If I were to switch out, I'd probably get a Kinesis Advantage (I once had a QD Ergo Pro) or a TEK or a TypeMatrix thanks to suggestions in this thread. All three have straight-line keys.

The old ergo I had wore out because I think it was a pre-cherry design.

<comment><USER4> > That's not a context switch.

What slows me down isn't necessarily the same as what does you. _I_ find it difficult to start engaging with a pointing device after using a keyboard, though as I said, it is quite fast for many tasks once you're already in that mode.

Furthermore, it's possible that I am simply out of practice using pointing devices, because I don't generally—when drawing or modelling I use a tablet. Absolute space is _very_ different from relative space.

</comment></comment></comment></comment></comment></comment><comment><USER6> I got a das keyboard at home and at work. Its awesome, and I'd recommend a mechanical to anyone who works on a keyboard for a living. I would never buy anything like this from Atwood, though. His 'expertise' in software, personal attacks on other developers and tedious self-promotion don't really convince me that he's got the know-how to get into hardware production, but rather that he's found a way to make money off his sycophantic fan-base of mediocre programmers who take his word as gospel.

(remember Arringtons tablet, anyone?)

<comment><USER7> Yeah, I have 2 DAS keyboards as well. Got em a few years back and they are so much better to type on. Mine have no letters on the keys so people that can't type don't just come to my desk and "Hop on my machine"

<comment><USER8> It sounds really cool, but in practice having unlabeled keys has just been tiresome for me. The numpad symbols and F keys always mess me up, and I'm hopeless when it comes to trying to print screen. Also the Cherry MX Blue switches are amazing for typing but not that great for gaming since there's so much dead space between subsequent taps of the same key.

The point is, don't just buy a Das keyboard to hop on the bandwagon. They do have disadvantages.

</comment></comment></comment><comment><USER9> I really can't think of anything good to say about this keyboard. I've used keyboards like this, and I've damaged my body with them. You know what matters a lot more than a backlight? Ergonomic design. Get a Kinesis Advantage instead.

<comment><USER10> As someone who has suffered from RSI, my advice is to not fix a problem you don't have. I've been there, and it just cost me money.

In my case, I didn't need a curved keyboard or a split keyboard, those things ended up in the cupboard. I just had to get rid of the numpad to change my position from awkward to healthy. So, for me, this keyboard is actually interesting, the variant without the numpad that is.

<comment><USER11> Why does the numpad make your position awkward by its presence? Can't you just pretend it's not there? Every keyboard I've owned since the late 80s has had a numpad and I've hardly ever used it.

Oh never mind, I see your reply to the top post below now. Because it moves the mouse too far away.

<comment><USER10> It forced me to either move the keyboard too far to the left or the mouse too far the right, the former causing wrist pain in both hands, the latter causing pain in the right wrist.

So, what fixed my pain was the smaller keyboard, not the lack of a numpad. The numpad just happends to be a big, expendable chunk :)

One of the keyboards I got in order to fix this was a Microsoft ergonomic keyboard, which includes the numpad and is also wider than what I've used before. So getting an ergonomic keyboard actually made things worse in one case.

<comment><USER12> I had the same problem and solved it by switching the mouse to my left hand. It was awkward at first but then I got used to it.

I move my left hand about three inches to get the mouse. With my right hand (using the old MS split keyboard) it was nearly a foot!

<comment><USER13> But then how do you cut and paste? Ctrl-Z, X, C, V are going to be hard to reach if you're mousing with your left hand.

<comment><USER14> Context menu select?

<comment><USER13> With a mouse in your off hand? That's got to be slower.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER15> I don't want to take anything away from Jeff, good for him for realizing his dream. But claiming that this is the best keyboard for programmers is an overstatement if I ever heard one.

Yes, it's mechanical, yes it has backlit keys and you can do some customizations. But where is everything else? Why are the keys still in the zig-zag formation? Why is the enter key so small? Why is the enter key on the right, where I have to use my pinky to hit it? Ever heard about ergonomics? Can I get one with DVORAK layout printed on? And so on and so forth.

If you want to create the best keyboard for programmers then create one that won't kill our wrists and hands.

<comment><USER16> You can choose Dvorak, Colemak, QWERTY via dipswitches on the back. As well as Mac (Alt/Command), disable Windows Key, switch Caps Lock with Ctrl, etc.

It comes with a key puller, so you can easily swap the keys with whatever keycaps you like. WASD sells tons of different keycaps.

I love ergonomic keyboards too but for a mass market item we wanted to follow the classic standards everyone knows first and foremost. Perhaps if the base model does really well, we can come back with an ergo model.

<comment><USER17> Do note that you will need new keycaps to use Dvorak or Colemak. Each row of keys in a WASD keyboard has a slightly different height/slope, so you can't move the keys around between rows (without having all of your keys being different heights, that is). You'd have to order new keycaps with the correct letters AND the right height/slopes.

<comment><USER18> ...or learn to touch-type, which anybody motivated enough to switch to Dvorak or Colemak is probably doing anyway.

</comment></comment></comment></comment><comment><USER10> Edit: Turns out they have a variant without the numpad, should have bothered looking for one! So, actually an interesting device. [http://www.wasdkeyboards.com/index.php/code-87-key- mechanica...](http://www.wasdkeyboards.com/index.php/code-87-key-mechanical- keyboard.html)

I'd be interested in this if it didn't have a numpad, or maybe a detachable numpad.

I guess everyone has their individual RSI issues, but after experimenting with various devices, I noticed that mine were caused _exclusively_ by that silly old numpad thing I never use anyway. It forced me to place either the keyboard too far to the left or the mouse too far to the right, causing strain in either my left or right hand over time.

I really don't see what use a programmer (or any touch typist) might have for the numpad. I really don't see why they put one on this keyboard.

<comment><USER19> They have an 87-key board

[http://www.wasdkeyboards.com/index.php/code-87-key- mechanica...](http://www.wasdkeyboards.com/index.php/code-87-key-mechanical- keyboard.html)

<comment><USER10> Ouch, I should have bothered actually looking for one instead of going ahead with assumptions, thanks!

</comment></comment></comment><comment><USER20> Other than for very specific ergonomic uses, I honestly don't understand the appeal of a heavy mechanical keyboard; the old IBM buckling-spring Model M keyboard doesn't appeal to me at all. Personally, I do all my work on a ThinkPad keyboard, and I actually have a USB ThinkPad keyboard/mouse for use with non-laptop systems or docking stations. I like the short throw of the keys, I like keys close together (as long as my fingers have room to type, which they do on anything >11" or so), and I like having a mouse on home row.

<comment><USER21> You can tear my Model M from my cold dead hands. Ya, when I'm on a laptop, I use a chiclet keyboard like everyone else. But I can feel myself typing with the Model M, my finger energy is returned fairly efficiently on each keystroke, it just feels better for coding tasks.

</comment></comment><comment><USER22> This is a very overpriced mechanical keyboard. The backlighting is silly and useless. Check out [http://elitekeyboards.com/](http://elitekeyboards.com/) instead. The Leopold keyboards are very fairly priced. The Rosewill mechanical keyboards from NewEgg are pretty alright, too. Filcos are on the higher end of the price spectrum but are a better value than the "CODE".

<comment><USER23> Also there's a lot of good-value Chinese mechanical keyboard imports (like the unbeatable Choc Mini).

NB one of the things you're paying for with the CODE is decent integration, I'm sure. I do have to USB->PS2->USB this Choc Mini keyboard to work with OSX (seriously!). It works fine though!

<comment><USER24> You can use this kext with Noppoo keyboards: [https://github.com/thefloweringash/iousbhiddriver- descriptor...](https://github.com/thefloweringash/iousbhiddriver-descriptor- override)

<comment><USER23> Whoa! Awesome, thanks!

</comment></comment></comment></comment><comment><USER25> I really don't see anything special about this keyboard. It's backlit and mechanical. Seems like it's been done a hundred times already.

<comment><USER26> When I saw the book mention below the first picture, I thought I misread and that this first picture was just the starting point before being inspired by code analysis found in the book. I imagined a new , more efficient, principled layout.

<comment><USER27> So did I.

For example, I'd think about reclaiming the top row, where the numbers live. On keyboards with a numpad, they're passengers. At the very least, invert the meaning of shift, so the default is to produce sigils.

<comment><USER26> Nice idea, even though I'd head toward a more dramatic different path.

<comment><USER27> Such as?

I mean the next step IMO is to borrow inspiration from some computer game peripherals and allow buttons to be physically laid out in a different way.

</comment></comment></comment></comment></comment><comment><USER28> This looks like any typical mechanical keyboard, like a DasKeyboard. I don't see what sets it apart?

I have 4 Microsoft Ergo 7000s in case they ever stop making them.

<comment><USER29> Cherry Clear switches, steel backplate and dip-switches for various options such as Mac compatibility...

<comment><USER30> Backlighting . . . man, tough crowd on HN.

<comment><USER29> So tough they can't even RTFA that consists mostly of pictures.

</comment></comment></comment></comment><comment><USER31> People might be interested in the Combimouse which is in development. It's a keyboard in two parts, where the right part doubles as a mouse.

[http://www.combimouse.com/index.htm](http://www.combimouse.com/index.htm)

Current Indigogo campaign: [http://www.indiegogo.com/projects/combimouse- combination-key...](http://www.indiegogo.com/projects/combimouse-combination- keyboard-and-mouse--43)

(Disclaimer: I'm not involved with this project aside from contributing to a previous campaign.)

</comment><comment><USER32> I had RSI. Got over it, but still found mechanical keyboards uncomfortable.

For some reason, I find the MacBook air 13 inch keyboard to be the most comfortable I've ever used.

I don't know why. Part of it may be the low height from the ground, and part is the great trackpad. (I tried the magic mouse and hurt my arm)

I expect other people have different opinions of the air's keyboard. The point is that I don't think there is any one keyboard that works best for everyone.

<comment><USER33> Scissor switches can be quite comfortable, and the macbook air has quite nice switches (IMO I like the thinkpad x1 carbon's a little better, but it is close), and the location of the trackpad being under the keys is much more comfortable than having a physical mouse to the left or right.

For my desktop I have a kinesis advantage, but I often find using my thinkpad for long periods of time to be very comfortable, I just wish I could find a decent trackpad for my desktop(s).

</comment></comment><comment><USER17> WASD Keyboards (well, Weyman) has given me some of the best customer support over the past few years. They even recently fixed my busted Caps Lock key (my own fault) outside of warranty for just $10. I broke my space bar in-warranty, and it was fixed for free. I wanted some custom settings/layouts the keyboard designer couldn't handle, and they obliged. My WASD has lasted for several years now (including a few minor repairs) and I've had nothing but good experiences with them. I've been waiting for their v2 keyboards (they've been "coming soon" for months) and I'm excited to see they finally launched!

</comment><comment><USER34> While I can understand the appeal of mechanical keyboards (at least appeal for you but hatred from your coworkers), I really don't understand why any programmer today is still using a non-ergonomic keyboard. These straight keyboards will kill your wrists, forehands and tendons eventually.

If you intend to be typing on a keyboard for more than the next five years and you're still using a straight keyboard, do yourself a favor and buy a split keyboard today.

Pains from Carpal Tunnel Syndrome will most likely follow you for the rest of your life, just not worth it.

<comment><USER8> You can type on a straight keyboard with your wrists turned in like with an ergonomic keyboard.

<comment> T-hawk Absolutely. That's my natural position and I've been typing hours per day for 20 years with no signs of stress injuries at all.

A good way to describe it is that the home keys are not asdf jkl; but rather more like qwdc mkp[ . I don't have any real fixed home position though, my wrists always "float" over the keyboard. Particularly the right wrist spends more time near the brackets and slashes for programming.

</comment></comment></comment><comment><USER35> I wonder what was the real price of making this keyboard, probably not more than $10. I mean China.

This is getting ridiculous. It's not because there is now HN, reddit and everything that can feed a hipster that you should fall into this trap and buy a €149.99 a keyboard.

<comment><USER36> These keyboards come with Cherry MX switches. Very hard to find them cheaper than $1 a piece. For a 104 key keyboard that's already over $100 :)

In addition to better feel and ergonomics [1], switches also have better maintenance properties. If one goes bad, easy to replace. If something spills, easy to clean.

With non-switch keyboards once a key stops working unless it's just a hair blocking the contact, the whole keyboard needs to be replaced.

[1] Feel and ergonomics are definitely debatable, but I'm just super happy for the switch to Filco Ninja Majestouch-2 tenkeyless ~ a year ago.. Before that I was a big fan of cheap Logitech UltraX keyboards but a after even a day with switches, UltraX felt like something unconsistent, blocking and muddy.

<comment><USER35> You are one example of people falling into the trap, sadly.

$1 a piece is the price you get in the US, and as an individual trying to buy Cherry MX switches from a company that already bought them for a lower price.

In china things are different, and when you are a company and buying in bulk, the price can go to as low as $0.2 for a switch.

This keyboard is ridiculously overpriced. I am against this because it clearly shows the guy just wants to exploit this "kickstarter" mindset and HN entrepreneurship culture of "price high" and people will think it's revolutionary.

This reminds me of the beats by Dre headphones.

<comment><USER37> > This reminds me of the beats by Dre headphones.

These are the same price as a standard WASD keyboard. There is no premium for the "Code, by Jeff Atwood" name. Also, they are comparably priced to "Das Keyboard" ($125) which is a comparable product which has been in production for a while.

Finally, if you want a "high-price geek-out" item, look at the "Optimus Popularis" keyboard, only ~$1090!

<comment><USER35> The biases in your reasoning lies in the fact that you are assuming I am considering "Das Keyboard" and the likes to be reasonably priced. I am not. Don't try to justify an overpriced item by showing me another overpriced item in the same category.

</comment></comment></comment></comment></comment><comment><USER38> Can anyone who has used the Cherry MX clears comment on them as compared to blues or browns? I've found that I dislike blues, and loathe reds. Browns are hands down my favorite, and the key switch I use both at home and at the office.

I do understand being frustrated in the search for a high quality mechanical _backlit_ keyboard, as there are shockingly few contenders out there. I'm currently using a Max nighthawk (green backlit with brown key switches), and enjoying it. However, the Ducky Shine II was very close to the top of my list.

<comment><USER16> Clear is sort of like blue without the noise. It's a strong actuation force, closer to real buckling spring keyboards... but without the deafening gunshot sounds every time you press a key. :)

</comment></comment><comment><USER39> What I would really like is a version of the Microsoft Ergonomic keyboard, that is backlit + mechanical. And WIRED, please, I hate wireless keyboards.

<comment><USER40> > _I hate wireless keyboards_

...until you hook up a PC to the big TV screen in the living room. ;) Then you'll beg for a good wireless keyboard.

<comment><USER41> Right, but most of us can buy any wireless keyboard, or even get a cool remote/keyboard combo, but a good ergo mechanical backlit keyboard for not a million dollars? nah.

</comment></comment></comment><comment><USER42> Mechanical keyboards are awesome and after a year+ typing on them I can't stand typing on regular rubber domes. My favorite switch is the MX Brown, as the Blues got annoying to me. My current keyboard, which I think is a better coder's board, is the tex beetle ( [http://i.imgur.com/ivEH2Av.png](http://i.imgur.com/ivEH2Av.png) ). If you want to go down the mechanical keyboard rabbit hole I recommend checking out [http://www.reddit.com/r/mechanicalkeyboards](http://www.reddit.com/r/mechanicalkeyboards)

</comment><comment><USER43> "I'm just happy to live in a world where the first truly great mechanical keyboard finally exists now." That's subjective. To me this keyboard is average and over priced. I personally hate that keyboard layout, so for me, this isn't the first truly great keyboard.

</comment><comment><USER44> Why are we continuing to use staggered layouts on keyboards? It is clearly inefficient, and not difficult to switch to a matrix (ie. grid based) layout, since all of the keys are close to where they were before.

Second question - in this day and age of easy connectors, why are numpads attached to the side of keyboards? What do left handed people do? Or people who don't use the numpad? Why not have the numpad detachable? Same goes for the arrow keys.

<comment><USER45> There's an easy fix for the "staggered" layout problem: type "Z" with ring finger, "X" with middle finger, "C" with index, etc.

It's beyond me why the "Z with little finger" technique is so widespread. It's universally taught, yet you're obviously bending your fingers in an uncomfortable and unnatural direction when you go to press the bottom row.

No one's complaining about the staggered layout of the right-hand keys, because it matches how your fingers bend. Staggering is great when it matches the natural angle of your fingers on the keyboard.

<comment><USER44> I don't think on the right side it matches either. From J if I move down I always hit between N and M. Actually, at least on my keyboard, I think that the right side is worse - I find myself in a position where my thumb is on the space bar, my middle finger and index finger do all of the typing, and my wrist constantly shifts to hit enter.

On the left side - if I hit Z with my ring finger. If I wanted to type ZERO, normally it would be Z(pinky) E(middle) R(index) O(right ring), but with this the easiest is to hit E and R with the index finger.

Anyway, doesn't make sense to have to hack around a layout whose only purpose was to key mechanics to not jam in typewriters.

<comment><USER45> Your hands and forearms should be hitting the keyboard at an angle, due to the way your elbows hang outside your shoulders. Don't bend the wrists to make your hands go perfectly vertical; that's a major RSI concern.

At that angle, the U/J/M and I/K/Comma rows, etc., should line up pretty well with the bending of your fingers. Same with E/S/Z and R/D/X. But Q/A/Z (how most people type) requires a completely unnatural bend!

</comment></comment></comment></comment><comment><USER45> I'm still waiting to buy a mechanical keyboard with a TrackPoint. Until then, the ThinkPad external USB keyboard [1] is perfect. Its big delete key is great, too.

[1] [http://shop.lenovo.com/us/en/itemdetails/55Y9003/460/60AC6A0...](http://shop.lenovo.com/us/en/itemdetails/55Y9003/460/60AC6A0372B14F5BA7B12F1FF88E33C7)

<comment><USER46> I've got two old Model M 13s with trackpoints. Unfortunately, the buttons on one of them are failing. I never realized how much I used the trackpoints till they didn't work.

</comment></comment><comment><USER47> What about the Happy Hacking keyboard? [http://en.wikipedia.org/wiki/Happy_Hacking_Keyboard](http://en.wikipedia.org/wiki/Happy_Hacking_Keyboard)

<comment><USER48> I use a HHKB Pro 2 and I believe it's as close to keyboard perfection as humanly possible. It's evident from the pictures that it partially inspired this CODE keyboard.

<comment><USER49> I'm thinking of giving a try to mini-keyboards, but I also use the arrow keys/pgdown/pgup frequently. So I have 3 tenkeyless for now.

<comment><USER50> I'll add my voice to "the HHKB2 is the greatest keyboard imaginable."

Also, re: arrow and paging keys, I manage to avoid them as much as possible, but reaching for 'Fn' with the pinky and hitting the appropriate key with my index or middle finger became second nature rather quickly.

Also, rarely noted — and the thing that every single keyboard gets wrong, including Atwood's here — is that the HHKB has the Escape key in line with the number row, so that it can be reached easily without taking your fingers off the home row.

For us vim users, this is really excellent.

I am _very_ happy with it.

<comment><USER49> Have you tried the Realforce? I'm more interested in it than the HHKB because of the ergonomically weighted keys (jrockway here says he likes them).

<comment><USER50> I haven't tried it, no. I'm big on the HHKB's layout, so the Realforce didn't really interest me.

</comment></comment></comment></comment></comment></comment><comment><USER51> This keyboard looks awesome. Another mechanical keyboard that is very interesting is this new split-design one: [http://ergodox.org](http://ergodox.org)

<comment><USER52> I built myself one of these, and they are awesome. Mechanical switches and firmware that you can tweak and compile yourself:

[https://github.com/benblazak/ergodox- firmware](https://github.com/benblazak/ergodox-firmware)

</comment></comment><comment><USER53> I was hoping for a mechanical keyboard laid out like the Microsoft Natural Keyboard. This one looks just like every other mechanical keyboard.

<comment> r-s I would buy that. I have very large hands and this keyboard is the most comfortable one I have ever used by far. I have a good mechanical keyboard which caused me nothing but pain.

</comment></comment><comment><USER54> I don't understand the fascination with clear/grey switches - blue/green's really aren't that loud compared to buckling spring's and you get the full double-dip feedback. If you're in a super-quiet office then I agree, it makes a difference - but why would you have an open office that didn't have a good deal of collaboration/talking/acceptance of noise?

The disable switches on the back of the keyboard are a very nice touch but beyond that, there is a lot from the ad that's standard fare for higher end keyboards these days. That price really needs to go down by 20-30$ for it to stay competitive beyond the initial rush of Atwood fans.

</comment><comment><USER55> No offence to the maker, but this seems like a huge gimmick. There's nothing that separates this mechanical keyboard from others in the same price range, and there certainly isn't anything about it that makes it more developer- friendly than other boards. They've just slapped the letters CODE on the back and called it a keyboard for devs...

</comment><comment><USER56> Anyone have any thoughts on the difference between this 87 key keyboard and the leopold tenkeyless? I've been using an ancient wired 87 key apple keyboard that I love but I'm intrigued.

[http://elitekeyboards.com/products.php?sub=leopold,tenkeyles...](http://elitekeyboards.com/products.php?sub=leopold,tenkeyless)

<comment><USER57> Things missing from the Leopold:

1\. Backlighting 2\. Better Aesthetics 3\. Cherry MX Clear switches

That's pretty much it. I personally don't think it's worth the 50 dollar premium when I'm just fine with MX Browns.

<comment><USER58> Got to agree with you here, the keyboard is quite overpriced (IMHO).

I'm with an 87 keys with brown switches at the office and at home I use a Das Keyboard with blue switches.

For me it's either brown or blue, clear switches are too much in between. If you're going non-clicky pick brown or even red, if it's clicky, then it's blue all the way.

</comment></comment></comment><comment><USER59> Here's an idea for a new keyboard. Just a board with studs like in Lego, and a bag of individual keys (switches), that you could arrange on the board in any way you would wish.

So you could build, in a way, any physical layout you would want. You could go fancy and use colored switches. And so on.. endless possibilities.

</comment><comment><USER60> I have two questions:

1\. I want to engrave international symbols by myself. Will they have a backlight like original symbols?

2\. Many people around the web are very pleased with their Cherry MX based keyboards. This is understandable when they are switching from cheap keyboards with same keystroke length. But what about people that have switched from laptop or Apple keyboards with shorter keystrokes? I found for myself that twice shorter keystroke is also twice comfortable (much less movements for fingers). Does it make a sense to try again a keyboard with long keystrokes, but with good mechanics like the CODE? Has anybody tried to use CherryMX keyboard after using laptop or any other keyboard with short keystrokes? Could you share your experience?

</comment><comment><USER61> Mandatory reading when it comes to keyboarding: [http://oreilly.com/news/zenclavier_1299.html](http://oreilly.com/news/zenclavier_1299.html)

So far, I've used many keyboards. Nothing comes close to the IBM Model M, or their modern incarnations. Here in India, you get a TVS Gold keyboard which is the basically IBM Model M of India. The difference between that and my office HP standard keyboard is so enormous, I can nearly write a short book detailing it.

Firstly the build, Model M's ones are built like a tank. They will last decades. Secondly the spring feedback and clicky auditory feed back you get. Thirdly, and the most important feature of the keyboard is the impedance match when your fingers hit the keyboard and the resistance/friction those keys offer. The Model M some does this so well, you will almost feel you are becoming one with the keyboard, combined with this the clicky auditory feed back and the rugged build is what makes the IBM Model M the king of all keyboards.

Now every time I use the Model M at home and then come and use the keyboards at office, I see two straight issues. One I see is either the keyboard is offering too much friction/resistance which in case my fingers hit the keys faster but the keys don't mechanically respond as faster, or in cases of keyboard like the Apple's flat aluminum keyboard the resistance is too less and fingers tend to slower compared to the keys. And yes the feed back thing isn't in any way remotely comparable to the Model M.

Lastly you can argue that, this should even matter to you as a coder. As good coding is above typing skills. Though I agree with you, I would suggest you read the article I posed at the top of this comment.

Beyond all, once you've some really awesome. Even the very normal all begins to feel like bad.

Long story, short- a good geek/nerd keyboard needs to:

        1. Provide auditory feed back while typing.
        2. The impedance match between the key response and
        your finger's hit force need to match perfectly.
        3. Keyboard must be rugged.
        4. Important code related keys should be big.

</comment><comment><USER62> I don't really see the benefit of a backlit keyboard, especially for programming.

<comment><USER63> it's for typing in the dark

<comment><USER64> Still puzzles me: who touchtypes looking at the keys?

<comment><USER63> a lot of people.

none the less, i consider myself a better typist than average. i don't touchtype, certainly. still, i find it really difficult to orient my hands with respect to the keys if i can't see them. the backlight is helpful for when i'm putting my hands back on the keys.

<comment><USER64> Thanks. I mostly use the bumps on F and J for that. I guess I do look down when my hands are way off and not finding the right bumps right away; the light from the screen seems adequate then. _shrug_

</comment></comment></comment></comment></comment><comment><USER65> Not sure if it's the font or actual size of the letters, the labeling on the keys looks really, really small.

Apple/Lenovo have perfected keyboards in their laptops. It's been years since I've wanted an aftermarket one.

</comment><comment><USER66> The perfect keyboard for me is the Logitech Wireless Solar K750, but it has 2 big flaws:

a) It discharges in around 3 days of heavy coding, and requires real sunlight, I had to leave the keyboard at the garden when the battery exhausted, and there are no alternate ways to charge it (the least I expected was a detachable USB cord).

b) Hardcoded limit of 40 pairings and no indication of that limit unless it won't pair anymore, I used to have two "Unifying receivers", one at home, one at the office, so I exhausted that limit relatively fast... It was frustrating and disappointing when I reached that limit...

</comment><comment><USER67> I've been testing out various keyboards, also the mechanical ones. The one that I have liked most is the Apple wired keyboard (with numpad). Since I'm using this with windows I remapped a few keys[1] to make it for more suitable for my habits.

The keyboard has low profile and the feeling on the keys is "very precise". Also it is quite affordable.

[1] [http://juhap.iki.fi/webdev/keymapper-mappings-for-using- appl...](http://juhap.iki.fi/webdev/keymapper-mappings-for-using-apple- keyboard-with-windows/)

</comment><comment><USER31> I love my MS Natural Ergo 4000 keyboard. Straight keyboards feel cramped and awkward. Every now and again I take it outside and blast it with the air compressor to clean it out, and it has lasted so long the type has worn off the middle row.

The nubs of the J and F keys had also worn down that much that I ended up getting an old soldering iron and scarring those two keys again.

I suspect ergo keyboards are not as advantageous if you are a hunt and peck rather than a touch typist (most useful thing I ever learned in school.)

I like the dip switch options on Jeff's keyboard.

</comment><comment> __--__ I've got to be honest, this thing is making me want to upgrade my CMStorm Quickfire. It really is the little details that I can appreciate, like backlighting, dip switches, the different layout for the function keys and the possible weaponization via steel backplate. I somehow feel better knowing I can defend myself with my keyboard. :D

I see the code keyboard as filling a void in the mechanical keyboard market between filco/wasd/cmstorm and happy hacker in terms of configurability and simplicity.

</comment><comment><USER68> I've been using a UNICOMP UB4044A ([http://pckeyboard.com/page/UKBD/UB4044A](http://pckeyboard.com/page/UKBD/UB4044A)) since mid 2007 and it. is. fantastic. I love the tactile feedback from the keys. My co-workers even find the noise from the buckling springs comforting when I'm typing fast and furious knowing that work is getting done. I highly recommend it at $80.

</comment><comment><USER69> Keyboard preference is something that takes a while to build and a while to undo, if you use just one. I have a few Matias tactile kb's (deep key travel) and a couple Mac aluminum wired kb's (laptop like key travel), use both simultaneously

(I also switch between piano, woodwinds, guitar/fretless bass and sometimes cello, which is _Hors catégorie_ as far as the complexity of the left hand action compared to the other three

</comment><comment><USER70> Uh... I see no value in this. Why not talk about a keyboard with language specific placement of letters? Who cares about a super basic and generic keyboard?

</comment><comment><USER71> Using a Unicomp Customizer 104 at home, and one with the trackpoint at work. Love them both, though don't use the trackpoint much... I have a TSR for Win+[]\ (volume down/up/mute respectively and that is all I really need.

Though they're really noisy (buckling spring), so the cherry clear switches on the CODE Keyboard do appeal to me. I'd like to see an option for mac key layout though.

<comment><USER72> The CODE has a dipswitch to change it to a mac layout. If you need to look at the keys to work with your layout, that's a different problem all together

</comment></comment><comment><USER73> It should go without saying that keyboards are highly personal, especially for developers. Having said that, this keyboard looks pretty terrible to me - nothing novel and all the things I dislike in standard keyboards. Really, a keypad?

Look into a $100 10 keyless cherry switch keyboard for a big improvement (filcos are particulary good). Or my favorite layout, the happy hacker keyboard pro.

</comment><comment><USER74> Topre switches on an ergo layout, no numkeys plz!!!

</comment><comment><USER75> Order website is confusing:

"Availability: In stock" at the top of the page, and then below in the product description says "We are now SOLD OUT".

So which is it?

Also surprised that the key caps are ABS plastic instead of PBT at this price point or at least there's no option for that.

Nevermind though; I'm going to wait for a few reviews of this to be posted. (Someone please post a review if you get one!)

</comment><comment><USER76> Does it solve the key rollover problem?

[http://superuser.com/questions/73685/keyboard-doesnt-let- me-...](http://superuser.com/questions/73685/keyboard-doesnt-let-me-press- certain-keys-at-the-same-time)

I've always wanted a keyboard that let me press as many keys as I want to at the same time.

<comment><USER77> From the site:

> We know you live and die by keyboard shortcuts. We do too. On the CODE > keyboard, up to six keys can be pressed at once, which is known as 6-Key USB > Rollover.

([http://codekeyboards.com](http://codekeyboards.com))

<comment><USER78> More importantly, it's got a PS/2 adapter, and that supports N-key rollover.

</comment></comment></comment><comment><USER79> I bought a Filco Majestouch and couldn't use it a work as it totally hurted my wrists. I really had to adapt to not hit the keys too hard. Also the cherry mx blue caused difficulties for navigating inside code because the course of the key is longer and I often hit the keys repetedly when browsing code.

<comment><USER80> I also bought a Filco Majestouch 2 with Brown switches. It just too high in the front so the wrists hurt and kind of heavy pushing down the keys so I go tired writing on it.

A bit of disappointment.

</comment></comment><comment><USER81> Looks a lot to me like a rebranded Ducky Shine ([http://www.tankguys.com/media/catalog/product/cache/1/image/...](http://www.tankguys.com/media/catalog/product/cache/1/image/9df78eab33525d08d6e5fb8d27136e95/i/m/imgp3156.jpg)).

<comment><USER16> I do like the Ducky Shine, but this is a 100% custom design that Weyman and I came up with. It's not supposed to look radically different, but much cleaner and minimalistic. The details matter.

<comment><USER82> Please go radically different next time! Now you've worked out the details you can go all out on the next model. Might I suggest this: [http://m.kbdmod.co.kr/product/detail.html?product_no=12&cate...](http://m.kbdmod.co.kr/product/detail.html?product_no=12&cate_no=4&display_group=1)

<comment><USER83> So is the price. Radically different!

</comment></comment></comment></comment><comment><USER84> Since he mentions Elon Musk, I just want to point out that this keyboard is about the cost of 1 share of TSLA.

<comment><USER29> Both are overvalued?

</comment></comment><comment><USER85> I'd think about this, but it isn't convertible to a UK layout. It's not just a question of keycaps - we have another key to the right of the apostrophe (~ and #) narrowing the return key, and the return key takes up the space of the \ and | key, with that moving to the left of z.

</comment><comment><USER86> If you make one with two extra keys under the space bar, for use as thumb- activated modifiers, and Cherry blue switches as an option, I will buy one. For now, it's not really bringing anything new to the table, except for those Cherry clears, but I don't care for them.

</comment><comment><USER87> I got really excited at first reading this, someone agreeing with me that keyboards nowadays were not evolving.

And yes good mechanical keyboards matter, but that's not what we should improve them on.

A good keyboard should have : usb 3.0 ports, mic/headphones entries, wheel to control the sound etc...

<comment><USER22> No. A keyboard should have keys for typing and nothing more. Do one thing and do it well.

<comment><USER87> I completely disagree. Where should I plug my microphone and my headphones ? Where should I plug my usb stuff ?

Only the mouse, the keyboard and the mouse are usually easy to access, the desktop tour is usually not. If I'm occupying a lot of space on my desk with a keyboard, I want it to be more than just a typing block. Believe me, I tried keyboards with jack plugs and usb sockets and it's amazing how a simple "evolution" they are.

As for the volume wheel, it's the best way to control the volume and the keyboard is the natural place to put it, where would you put it if not on the keyboard? On the screen?

</comment></comment></comment><comment><USER88> This is neat, but personally I don't find keyboards that exciting. Nor do I anticipate ever owning a desktop machine again. Maybe if this sort of thing could be done on a laptop, I'd be pumped.

My fave keyboard is still the IBM 101 clickity from my PS/2 days in school.

</comment><comment><USER89> I don't know if it's cognitive bias or what; but I've been using my iMac for about 5 months now, and the small keyboard that comes with it is fantastic. My wrists don't hurt, and the keys are crisp and clear to touch type on.

$150 for a keyboard is really steep.

</comment><comment><USER90> Honestly, if I were going to try to solve one problem with keyboards it would be to make cleaning them easier. This seems like a good keyboard and I may consider picking one up if both of my Das Keyboards fail me, but I'm not rushing to get one.

</comment><comment><USER91> What I would like is the possibility to buy/order a low-cost, non-mechanical, customized keyboard. Mass-manufactured keyboards cost less than 10€, could a custom printing job for the keys add that much?

</comment><comment><USER92> I'm a current Filco owner and previous Model M user. This looks like exactly what I would have produced if I could make my own keyboard. Ordered an 87-key, looking forward to trying it out.

</comment><comment><USER93> A proper coding keyboard would have the numbers A-F next to the numpad.

</comment><comment><USER94> Looks nice but I love my Cherry G80's (and they are less than half the price) too much to upgrade just yet (though the silent keys might be kind in a crowded environment).

</comment><comment><USER95> The nicest looking of the many mostly identical mechanical keyboards out there.

Should've gone with double-shot injection molding for durability; I wonder what it would have cost.

</comment><comment><USER96> I am typing on a Kinesis Freestyle set _vertical_ with its Ascent and it Kicks Ass(TM). You can't beat the ergonomics of a vertical keyboard.

</comment><comment><USER97> For $149 I would prefer PBT keycaps vs ABS.

</comment><comment><USER98> This sounds like a wired device? I've been looking for a good wireless mech keyboard for a while now...

</comment><comment><USER99> I'd get this one if it was curved and without the numpad to reduce the distance to the mouse.

</comment><comment><USER100> Backlight on a mechanical keyboard?

For me, that will just light up where the clumps of dust and crumbs are.

</comment><comment><USER101> Control key is the wrong place.

</comment><comment><USER102> This is a serious question: why does anyone want backlighting?

<comment><USER103> Gaming. If you want to game in the dark then it helps to have backlit keys.

</comment></comment><comment><USER104> Seems cool. I'd pull the trigger if it was wireless.

</comment><comment><USER105> Interesting. The checkout page is php. ;)

</comment><comment><USER106> Why include caps lock?

<comment><USER16> You can disable it via the dip switches, as well as a bunch of other tweaks available via same.

</comment></comment><comment><USER107> Meh, no QWERTZ :(

</comment><comment><USER108> Interesting stuff ... sadly with shipping and VAT + customs it will come close to 270 USD in Europe. But probably I will purchase one.

It is very close to the perfect keyboard for me - just add blank keys and replace the clear with green (I love the chaingun sounds early in the morning.

</comment><comment><USER109> As pretty as Jeff himself. I'm in for one.</comment>


New high-tech laser method allows DNA to be inserted 'gently' into living cells - <AUTHOR> http://www.sciencecodex.com/new_hightech_laser_method_allows_dna_to_be_inserted_gently_into_living_cells-117147 <comment><USER2> If this method really works it would be amazing for medical research. For instance, you could take a cancer biopsy and pull out DNA strands for individual cells. Using single molecule sequencing techniques we could then map the change of the cancer across the biopsy and learn so much about how it grows and transforms.

Current DNA extraction methods involve completely 'mincing' the cell and then trying to separate the mush that you get left with. When dealing with single cells this is far too clumsy! It sounds as if this new method would produce a clean way to get the DNA out of (or into) cells.

</comment><comment><USER3> Patient: "Will it hurt?"

Dr. Scientist: "Don't worry, I'll be gentle."</comment>


London tube map made from a working circuit board - <AUTHOR> https://www.ianvisits.co.uk/blog/2020/06/23/check-out-this-london-tube-map-made-from-a-working-circuit-board/ <comment><USER2> I like this but one thing - it looks like the lights only show if a train is at a station , then goes off once it leaves, so seemingly you have random lights - instead of a light traversing a path. Or did I misunderstand looking at the gif?

Update: I do love this project I would really like this to be resolved so it's perfect perhaps lights should stay on until the train reaches the next station?

<comment><USER3> Hi, Richard here from Traintrackr

As others have mentioned, there are more trains running than there are station LEDs, so in central London the LEDs would almost always be on, which didn't look as good.

For the MBTA in Boston we added LEDs in between each station, and even went further and added LEDs for each direction, but with only 4 lines it was much easier to put together - [https://www.traintrackr.co.uk/product/mbta4](https://www.traintrackr.co.uk/product/mbta4)

We're looking into this for London, but making it look good is significantly more complex with the number of lines and large interchange stations.

<comment><USER4> Your projects look amazing, contragulation ! You could fade the led to depict the train distance to the station ? Like that, you would have a nice transition between stations, and if there are multiples train incoming/going from it you sums the intensities ?

I think it would add another level of smoothness to it.

</comment></comment></comment><comment><USER5> I had a go making something similar with an e-ink display, albeit much less refined.

[https://www.rrayns.co.uk/posts/29-09-2019_e-ink-station- watc...](https://www.rrayns.co.uk/posts/29-09-2019_e-ink-station-watcher.html)

</comment><comment><USER6> This is so cool, especially because the Tube map was inspired by a circuit diagram in the first place!

[https://tfl.gov.uk/corporate/about-tfl/culture-and- heritage/...](https://tfl.gov.uk/corporate/about-tfl/culture-and-heritage/art- and-design/harry-becks-tube-map)

<comment><USER7> "Incidentally, the story that Harry Beck based his original map design on the electronic circuit board is a myth. There is indeed a Beck style circuit board design tube map in the archives, but it was apparently a joke that was presented to him long after the tube map had been adopted by London Transport."

from TFA

<comment><USER8> That exact phrase pops up a lot (like it gets pasted verbatim around the net) but I've yet to see any evidence to corroborate it's even true. Where as it has been widely reported by a number of independent sources (Beck's family, the Transport for London, etc) that Back's plans were based on circuit diagrams. So I have a hard time believing the 'myth' argument is more trustworthy.

Please also note when they talk about Beck's inspiration they say "circuit _diagram_ " and not "circuit _board_ ", like the paragraph you quoted.

<comment><USER9> As far as my brief research shows, Harry Beck came up with his original tube map design in 1931 (which is actually quite different to what we know it as today btw), while the first printed circuit board was invented in 1936 by Paul Eisler. Thus while it's possible that Harry Beck was inspired by circuit diagrams, it's surely not possible that he was inspired by (printed) circuit boards.

</comment></comment></comment></comment><comment><USER10> I think nicer are these real time mini tube departure boards, apparently you can get them customized for any station on the network: [https://www.youtube.com/watch?v=EgLGKjj3GwI](https://www.youtube.com/watch?v=EgLGKjj3GwI)

<comment><USER11> See also this Tiny Train Departure Board: [https://hackaday.com/2019/08/05/a-tiny-train-departure- board...](https://hackaday.com/2019/08/05/a-tiny-train-departure-board-just- like-the-real-thing/)

<comment><USER12> And this one which I think looks really slick as well. [https://hackaday.io/project/9690-tram-departure-time- indicat...](https://hackaday.io/project/9690-tram-departure-time-indicator)

</comment></comment></comment><comment><USER13> It seems to require an account to set up and use: [https://www.traintrackr.co.uk/setup](https://www.traintrackr.co.uk/setup)

</comment><comment><USER14> I think it would be cool to make a mosaic of such circuit boards, one per European city with a subway, arranged in the shape of Europe.

<comment><USER15> Or flights.

[https://www.flightradar24.com](https://www.flightradar24.com)

</comment></comment><comment><USER16> I absolutely love this! But during busy times many lines have trains separated by <= 2 stations (often < 3 minutes between trains on Victoria line), so one would expect most of the lights to be on. How does it decide which trains to draw?

<comment><USER17> The trains typically stop for ~16 seconds at a time. Even on say 8 platforms thats under 3 mins. Plenty of time for gaps between lighting up! (could also alternate colours with blinking)

</comment></comment><comment><USER18> Visual open data! It's not clear to me in America if I can buy the 'Tube' one. I've spent quite a bit of time in London and it just interests me more. Wonder if they'd also consider making a Paris Metro one?

<comment><USER3> The London boards are for sale in the US - [https://www.traintrackr.io/product/](https://www.traintrackr.io/product/)

Paris is certainly on the list for future maps.

</comment></comment><comment><USER19> This needs a live version of each board shown online. This would give you an idea of the utility. So, right now, the UK rain map should be pretty idle since it is a very sunny day, at least in the south. The tube map should be something you can watch for a few minutes to get an idea as to how it updates itself.

The Boston board has the station names etched onto the board. Clearly the London large board could have some names etched in. London has a lot of tube stations though so this could result in a lot of visual clutter. But trains do have their destinations and 'via' on the signs, e.g. 'Cockfosters via Bank'. The names of the termini stations (e.g. Paddington, Liverpool Street) as well as the end destinations (e.g. Morden, Richmond) and major intersections (e.g. Oxford Circus) could be provided, making the map a bit more inclusive and usable for those that don't have the map etched on their brain.

</comment><comment><USER20> If you like the look of this and want it as a phone case (...with reduced functionality), you can get it...for a steep price (when they're not sold out!)

[https://www.moeco.jp.net/search?q=london](https://www.moeco.jp.net/search?q=london)

</comment><comment><USER21> Reminds me of a functional radio built out of the tube map I saw at the London Design Museum a few years ago: [https://www.designboom.com/technology/yuri- suzuki-london-und...](https://www.designboom.com/technology/yuri-suzuki- london-underground-circuit-map-radio/)

</comment><comment><USER22> I wonder where he is getting the data from. I'd love to have live data from the Barcelona subway network. It happens a lot that I arrive at a station and a train is just leaving. During peak hours they go every couple of minutes but later at night it could be 10 minutes.

<comment><USER23> Transport for London have a fairly comprehensive API that has all kinds of live journey and network information: [https://api.tfl.gov.uk/](https://api.tfl.gov.uk/) \- the article mentions that this project is using the API

Edit: Looks like TMB also have an API. I'm not sure how it compares to TfL's: [https://developer.tmb.cat/](https://developer.tmb.cat/)

<comment><USER22> Thanks! Yes TMB has an API, I looked at it before but it only provided scheduled service times, not live data like you can see on the boards in the station. But I'll have another look!

</comment></comment></comment><comment><USER24> I love this! There's something cool about seeing live data physically, like a little simcity running on your wall/desk. I like that it's not tied to their servers, in the event they decide to quit the business you don't have a paperweight.

</comment><comment><USER25> > _Personally I prefer the white version_

I initially thought the PCB is white, before re-reading preceding text. However, I then had to search for images of white PCBs, and they're very neat too.

</comment><comment><USER26> _" coloured lights for each line – except the Northern, which sticks with white lamps."_

What, nobody's invented a black LED yet?

<comment><USER27> 'It's the wild colour scheme that freaks me out,' said Zaphod, whose love affair with the ship had lasted almost three minutes into the flight. 'Every time you try and operate these weird black controls that are labeled in black on a black background, a little black light lights up in black to let you know you've done it.'

Zaphod Beeblebrox, The Restaurant At The End Of The Universe

</comment></comment><comment><USER28> Pure electronics, visually represents the subject, and manages to be functional. I see it as art.

</comment><comment><USER29> Cool, I think I'll do one for my home town of Warsaw....

What?! At least BoM will be lower!

</comment><comment><USER30> So cool. I bet the electrons travel by tube.

<comment><USER31> They don't; it's all solid-state.

</comment></comment><comment><USER32> looks really nice</comment>


Google Docs vs MS Docs. Wondering why Google Docs still sucks? - <AUTHOR> http://whydoeseverythingsuck.com/2010/04/google-docs-vs-ms-docs-wondering-why.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+WhyDoesEverythingSuck+%28Why+does+everything+suck%3F%29&utm_content=Google+Reader <comment><USER2> His argument basically boils down to that Google docs will always lag behind the desktop version of Office and, therefore, will always suck. On the other hand, Microsoft "clearly ... will have better editing features."

"I guess Google could just give Docs away" (they do already)

"Google's efforts with Docs seems like such a competitive joke" (even though they satisfy the needs of most basic document/spreadsheet authors, which is to say a _huge_ market).

The author conflates feature-parity with the market leader with product quality.

<comment><USER3> I disagree; I think the author's central thrust is that Google Docs hasn't improved as quickly as people expected. It's been around in its current incarnation (post-Writely rewrite) for 3.5 years now.

</comment></comment><comment><USER4> While I don't agree that Google Docs sucks (I think it's "adequate" - not a ringing endorsement - for a simple majority of users' needs) I would like to see improvements.

Here's why they are coming: Chrome OS.

Chrome OS is predicated on solid HTML 5 support and web apps just like Google Docs. You can't sell a billion Chrome OS netbooks to IT departments without a solid office suite.

We just saw gears getting phased out, now we'll see HTML 5 offline support phased in and then we'll see some new features.

I've gone crazy waiting for new features as well in google apps. For instance, contact sharing. Seriously. Why so long? As a consultant in these matters I'd like a better roadmap so I can reassure clients that features are either on or off the horizon.

<comment><USER5> Me neither. I've been using for everything for about a year now. when I upgraded to Win 7 I forgot to reinstall my copy of MS office and I don't really miss it. Microsoft's product is better but I don't need the advanced features all that often.

 _I've gone crazy waiting for new features as well in google apps. For instance, contact sharing._

Agree that further integration would be good, and things like project management and so on. Google has been advertising heavily recently about companies 'going Google' by switching to Docs, and there's great potential yet to be exploited.

</comment></comment><comment><USER6> _Presumably one of the most important initiatives at Google outside of search has got to be Google Docs. Having a platform for people to create and edit documents on the web has to have been seen as a critical feature._

Why? It's not at all clear to me why Docs should be "one of the most important initiatives at Google." Since advertising brings in the lion's share of Google's revenues, their priorities are probably:

1\. Search - where most of the advertising money currently comes from

2\. Android - where most of the advertising money will eventually come from

Also, considering that google's enemy-du-jour is now Apple, not MS, I wouldn't be surprised if Docs has slipped even further down the priority list.

<comment><USER7> A huge company like Google can not only rely on search and people liking their search to survive. They are always looking over their shoulder at this point, looking out for any new "Cool" company that will threatens their search bread. I think folks at Google are a bit worry at this time because the only reason why people still go for Google instead of Yahoo is still mostly the Cool Factor and likability thing; that is not a solid platform for a company to rely on.

So I think with Docs Google tried hard as they do every day to position themselves outside of search. It's like a great singer with only one popular song, who tries hard to come up with new stuff without convincing his fans.

</comment></comment><comment><USER8> I can only wonder how long until the whole model behind Word gets perceived as completely obsolete.

Word comes from the ages when you edited a document, passed it along and then printed it for someone who should read it. This is not what we do anymore.

<comment><USER9> I'm not sure about this, the only part I don't see happening anymore (at least, not as often) is printing. We still create and edit documents, then pass them along (email, IM, web, etc). Are you saying we'll have some completely new concept beyond documents?

That said, I still do see lots of printing. For example when we group together for discussions it is a whole lot easier to have a paper copy that I can doodle on, make notes, etc than to try and drag a laptop in (tablet or not).

<comment><USER8> > Are you saying we'll have some completely new concept beyond documents?

Don't know about you, but just about every important technical document here resides in a versioned wiki. If we print it for, like you say, discussions, the doodles are usually merged with the document in the wiki when the discussion is over. The wiki page (or pages) is _the_ document. It retains history, authorship and is the canonical reference for that information.

That said, this is more common in the IT-related areas. Lawyers, among others, tend to resist technical innovation. I just imagine how hard it was for them to adopt typewriters.

</comment></comment></comment><comment><USER10> I haven't used Microsoft Office as long as I can remember. I keep OpenOffice installed on my machines just so I'll be able to open certain documents that other people inevitably send me. For my uses google docs and basic text editors suffice and I imagine that there are millions of others like myself.

Lightweight, efficient, and fast are the core features I need.

</comment><comment><USER11> Not a fan of this article, many inconsistencies in it as @mmastrac points out but to be honest in the big company I work in points of view held by people making the decisions of what we all use are similar as of now so having this out is important.

</comment><comment><USER12> It is just me? I cannot find any reason, or arguments stated in this article. Just an opinion.

My opinion is, Google Docs rocks because 1) extremely portable, a keyboard and a chair is all you need 2) sharing of documents make it very useful 3) can convert many different formats and export to PDF.

I have yet to find any reason to use anything else.

<comment><USER13> _I have yet to find any reason to use anything else._

For lightweight text editing and easy document sharing, GDocs is perfectly adequate. For more serious document preparation (i.e. when you care what the output looks like), it still has a long way to go. The recent improvements are great, but I'm a little surprised Google haven't devoted more resources to it.

<comment><USER14> I'd really really like to see an export API which exposes the document features and allows people to export differently/to different things.

</comment></comment></comment><comment><USER15> Hooray for competition! This can only spur Google a bit to improve Google Doc's feature set. Why does the author think one service must live and one service must die? There's always room for choice when services offer advantages over each other.

</comment><comment><USER16> Should probably take into considerations the upgrades to Google Docs that are currently being rolled out (<http://googledocs.blogspot.com/2010/04/new- google-docs.html>). Wave like real-time collaborative editing, entirely new backed that doesn't depend on browser editing quirks ec. I'm looking forward to them and think they will solve a lot of the annoyances I have had with document editing with Docs.

I say annoyances, because the value of collaborative editing and online sharing outweigh them.

</comment><comment><USER17> The only thing right about this article is that office applications online are not as mature as the desktop.

It would be much fairer to point out that applications in the browser are limited because the browser platform needs further evolution to make applications more usable and reliable. Google has taken quite a lead in this area. Including mechanisms for printing wherever you are, speeding up the browser and allowing users to work off-line. All without plugins.

Microsoft's offering relies on Silverlight for some features.

</comment><comment><USER18> I went to the microsoft docs site and didnt see an editor. You can edit docs via that website? If not, what is this guy comparing?

</comment><comment><USER19> "Google Docs vs MS Docs. Wondering why Google Docs still sucks?"

I assume because Google puts a lot of work in the api design.

Thats why it takes longer.</comment>


Ask HN: What is the number one thing you wish would happen in your life time? - <AUTHOR> What do you think would be the most epic, most special, most interesting or exciting thing that you could possibly happen during your life time? <comment><USER2> Reversing global climate change and bringing atmospheric/oceanic CO2 levels back to pre-industrial levels.

</comment><comment><USER3> People deciding to stop acting like savages towards one another.

</comment><comment><USER4> First Contact.

</comment><comment><USER5> AI machines becoming our parents and making decisions for us cause we're really bad at it</comment>


We Need A Standard Layered Image Format - <AUTHOR> http://shapeof.com/archives/2013/4/we_need_a_standard_layered_image_format.html <comment><USER2> TIFF, <http://en.wikipedia.org/wiki/Tagged_Image_File_Format> has been around since 1993. It supports layers. It supports compression. It supports paged(!) images. It has well-defined supported image encoding formats. It's already supported by all the image editing software you've ever used (from this millennia).

We _have_ a Standard Layered Image Format. HURRAY. NEXT PROBLEM, PLEASE.

<comment><USER3> Image formats have come a long way. I think the author wants an image format that can replace .psd in a sensible way. TIFF sadly cannot do that. While it can contain layered raster data, it lacks a lot of other capabilities. The author explicitly mentions vector layers, but if you want parity with .PSD you're looking at also having to support adjustment layers (hue/curves/levels/etc), blending modes, opacity/fill, raster masks, clipping masks, vector masks, locks, annotations, guides, grids, gradients, tags, text, comps, channels, and countless other things I can't even think to list (I wont even dive into smart objects). Keep in mind that's just the layer data, there's tons of other metadata in the format as well. It is a behemoth of a file format, and the years of backwards compatibility inside of it have multiplied that complexity to levels of insanity. I have .psd files that if I enable backwards compatibility when saving will increase the file size by half a gig. Granted those are enormous source files to begin with, but with higher def screens on the horizon file sizes are increasing dramatically. Having something more sensible than .PSD is something we're going to have to deal with sooner or later.

<comment><USER4> .XCF

<comment><USER5> Not really that is still as good/bad as .PSD is because of the nature of what the file is used for. They are both primarily containers for unfinished works and are designed to hold a lot of detail without so much regard for size and portability. Of course the .XCF format is open but not good enough for a simple viewer or even a web browser. Some file format based on SQLite will probably be more viable as a cross platform image format that is extensible beyond any one software developer limiting it. Kind of like HTML.

<comment><USER4> It meets all of the requirements of the parent post I replied to, plus it even has a pretty decent open source editor. It's internal structure may not be in SQLite format, but it is an extensible tag based chunk format. You shouldn't dismiss it so easily.

</comment></comment></comment></comment></comment><comment><USER6> FXG could have solved the single file problem by grouping all the files up and making a zip file, and picking a different extension. For example this is how Android (.apk) and iOS (.ipa) applications are distributed.

It also has the advantage that if you extract the zip you can now access whatever pieces are inside as separate files even by tools that don't understand the containing format. (eg a bunch of jpg/png inside the zip are perfectly viewable in any image viewer). Trying to do the same with SQLite is problematic as you have to write queries to grab the blobs and then dump them to disk.

Where SQLite as a format does shine is if you need to keep historical information such as an undo/redo log. That makes it good for an application format, but not for an interchange format.

<comment><USER7> Does the zip format let you replace an arbitrary file inside an archive without rewriting the whole file? It's not uncommon to see Photoshop files that are 400+ MB, and rewriting the whole file on save would have some pretty poor performance. The other examples of files that use the zip approach are either distribution-only (ipa/apk/jar) or generally don't get very big (word processing).

<comment><USER8> You can easily add new files at the end, then rewrite the central directory header (which is at the end of the file for exactly this kind of reason: not have to rewrite everything to add new files). And because the CDH specifies offsets to files, you can replace the old entry and put the new one there (replace old offset by new offset, done). This does however mean the old entry will still be in the file until you "garbage collect". That's if the new version of the file is bigger than the old one of course, if it's smaller or the same size you can just overwrite the old entry and not touch anything.

One could even imagine padding files in the archive so there's some leeway in growing the compressed files, it'd likely depend on the format expression.

<comment><USER9> This is however the sort of thing SQLite already does for you.

</comment></comment></comment></comment><comment><USER10> > Last summer, Adobe killed their image exchange format "FXG".

Edit: previously I had balked at this claim, but I'm wrong. While I can't find any official notice of its death, and it's still in use in Scene7 and somewhat supported in the open-sourced version of Flex, trawling message boards does indicate Adobe shying away from it in favor of SVG[1][2] and it's not supported in CS6 without an extension.

Still, his problem with FXG (or a format like it) seems superficial. Yes, FXG defines links to other assets instead of combining them into one file, but to me, that's a feature, not a problem: I can them programmatically swap out assets easily by just manipulating the references within the file. It makes it really useful for generating customized assets on demand. In practice, it's like HTML for layered documents. We don't complain that HTML is broken because it links to images instead of including them, do we?

If you don't like that you have to send a folder: zip it up and give it a custom extension if need be, a la browser extensions and Microsoft Office formats.

[1]: [http://mail-archives.apache.org/mod_mbox/flex- dev/201303.mbo...](http://mail-archives.apache.org/mod_mbox/flex- firstname.lastname@example.com%3e) [2]: [http://mail- archives.apache.org/mod_mbox/flex-dev/201303.mbo...](http://mail- archives.apache.org/mod_mbox/flex- email@example.com%3e)

<comment><USER11> We also don't typically use HTML as an interchange format between editors.

<comment><USER12> Well ePub is a zip file of HTML documents. So some people do.

<comment><USER11> Not really. Not only is EPUB not what I would consider an editor interchange document, but the HTML isn't even the format used for the "core" document file. An XML file with the .opf extension is the "core" file that describes how the EPUB works, and the HTML files are actually just content, analogous to the layer data in Gus's sqlite.

</comment></comment></comment></comment><comment><USER13> "I want a filesystem in a single file. I'll pick the one I'm most comfortable with and pretend that it's much better than separate files".

Meanwhile, we'll ignore all the semantic issues around the data. What exactly _is_ a layer? Any given image file? What if some tools only handle e.g. alpha- layers? What if a layer is actually a filter kernel?

How are the layers composited? How are they ordered? Is it a linear order, or is there actually a tree of layers?

The reason PSD works so well is only partially that things are all in one file. It's also that the semantics of its contents are extremely well defined. (OK, if you're willing to consider PSD documentation "extremely well defined")

And Gus is almost completely punting on that part - define _that_ well enough, and it might make sense. Until then, it's just another VFS with a blob of assets that the receipient probably can't parse exactly as intended.

<comment><USER14> Couldn't someone come up with a relatively sane schema for storing the same information that a PSD would contain in a SQLite database?

That way, you could standardize on the semantics that are already documented and familiar to other developers, but avoid the difficulties of the file _format_ , which seem to be the issue here.

* disclaimer: I've never had to write a PSD-parser, I'm just going on hearsay.

<comment><USER15> How about just strip PSD of all its crud, Adobe specifies it openly and gives it to the commons. I have a dream..

<comment><USER16> Keep dreaming: PSD is not a single file format, but two decades of cruft upon cruft:

<http://www.jwz.org/blog/2012/11/psd/>

<comment><USER17> I found this article, linked in the comments, to be insightful: <http://www.joelonsoftware.com/items/2008/02/19.html>

</comment></comment></comment></comment></comment><comment><USER18> It's not going to happen for the same reason a standard 3D format will never happen. (and no neither FBX nor Collada fit).

The problem is, at least in the case of image editors (and 3d editors), standard formats arguably stifle innovation because you have to break the standard to add anything.

Maybe you decide it would be be better if all vector colors were stored as HSVA instead of RGBA except now no one can read your files. Maybe you'd prefer to store floating point colors with values greater than 1.0 to represent light emission. Maybe the standard only defines circles but you want eclipses. Maybe the standard says circles are defined based on rounded rect with the maximum roundness but you'd like them to be based on a center point and radius. Maybe the standard doesn't support text on a path but you want text on path. Maybe the standard doesn't support linking paths so that if the text doesn't fit on one path it bleeds into another. Maybe you'd like to justify text across multiple paths but that's not in the standard. Maybe you like columns but that's in the standard. Or you want to be able to define areas to be cut into pngs, each area with a specifiable filename. Or you want some of the settings to be per animation frame but the spec never thought about animation so your SOL. Or you want layer fx. Or you want to add a new layer effect. Or you want to be able to embed a PDF as a layer. etc.. etc.. etc..

Photoshop's basic chucky format is well known. It's not that hard to write some code to read all the chunks you care about. Putting those chunks in an SQLite format will not make it any easier to deal with new chunks your code does not understand.

<comment><USER10> > The problem is, at least in the case of image editors (and 3d editors), > standard formats arguably stifle innovation because you have to break the > standard to add anything.

Indeed: that's exactly why Adobe created FXG instead of adopting SVG in the first place[1] (though they are now circling back to SVG).

[1]: [http://www.mikechambers.com/blog/2008/09/30/why-adobe- chose-...](http://www.mikechambers.com/blog/2008/09/30/why-adobe-chose-fxg- over-svg/)

</comment></comment><comment><USER19> Interestingly, in the GIS/Mapping space Mapbox has faced a similar kind of problem, albeit with image tiles rather than just layers. Their solution was to come up with an image format called mbtiles (<http://mapbox.com/developers/mbtiles>), which actually uses SQLite. It's not the same problem, but perhaps it throws some credibility to the use of SQLite as an on disk format for structured images.

<comment><USER20> ESRI Shapefile formats include a DBF file, which is a Foxpro database.

<comment><USER21> And I still dream of spatialite becoming the one interchange format to rule them all.

<comment><USER22> I just used Spatialite to create a tool for managing large stacks of images on the pixel level; i.e., each image gets its own database file, each pixel is stored as an XYZ coordinate and an RGB value.

I can use Spatialite's built-in functions to rotate, translate, scale, etc. images; and use SQL to pull out sub-volumes of the stack, edit and composite them.

My biggest stack is almost 2000 images, over 90GB uncompressed data. Working with subvolumes is pretty snappy up to a few hundred megabytes, which is good enough for my purposes. For bigger jobs it should be possible to parallelize some tasks for better performance.

Not entirely on-topic, but the takeaway is I'm thumbs-up for using SQLite to process image data.

<comment><USER21> Do you do anything in particular to improve access speed to that image data? I've been working with big matrices that get spit out of traffic assignment software that we use in travel modeling. Every vendor seems to have their own proprietary format. We ended up using HDF5 as a container due to its somewhat awesome speed characteristics. I'd initially tried SQLite for that matrix data, but couldn't squeeze the same kinds of performance out of it. That could have just been my own brain fail though.

<comment><USER22> Nothing beyond the standard advice for SQLite performance. I found that keeping the data in individual per-image database files worked a lot better than trying to create one big database for the whole stack. With that done, I expect the big performance win to come with parallelization of the image transformation tasks.

</comment></comment></comment></comment></comment></comment><comment><USER23> This whole idea seems totally mad from a distance but as a developer I'd love to be able to open complex files as DBs.

What would be the downfalls of passing around a DB as an image file? Does the compression suck? Does the performance suck? What makes this a terrible idea?

EDIT: to clarify, by compression I'm referring to the non-lossy type - I'm assuming that within the db you'd have already processed assets.

<comment><USER24> One downside would be that tools like file(1) that try to guess a file's format by examining its contents would return "SQLite database" for every image file, which isn't the most helpful result.

Since SQLite aims to be a generic way for applications to store data, it'd be nice if its "open database" and "create database" functions allowed you to supply, say, a 4- or 8-byte magic value that would be stored at a fixed location in the file's header so tools could distinguish _your_ SQLite-based file-format from everybody else's, without having to load the thing up and examine the schema.

<comment><USER25> There are currently 24 contiguous bytes of unused space in the SQLite header. If need be, and if SQLite catches on for use as a portable image format, I will be willing to allocate some or all of those 24 bytes to an identifier string for file(1).

<comment><USER23> This is surely one of the greatest responses I've ever seen on the internet. What was the intention with the unused space originally? Did you foresee this moment coming?

<comment><USER25> When designing a file format, it is always a good idea to plan for enhancements. There were originally 36 bytes of unused space in the 100-byte header of the SQLite 3.0.0 file format, back in 2004 - bytes set aside specifically to deal with unforeseen needs. Over the years, 12 of those bytes have been allocated to various improvements. 24 bytes remain. (I'd prefer not to use them up all at once or on a whim, obviously.)

<comment><USER16> Thank heaven for people like you.

</comment></comment></comment></comment></comment></comment><comment><USER26> > and Adobe, if you are listening you should really give SQLite a serious look

I'm not in the Photoshop group, but I do make liberal use of SQLite in the projects that I'm involved in at Adobe.

</comment><comment><USER27> I'm interested in why Acorn ties the concept of a layer so tightly to a bmp or shape blob rather then segregating the two. It seems that having a library table that the layer table links to would allow for better reuse of images.

Library table <\- pixel data

Layer table <\- heirarchy/duplication of library items

Attributes table <\- attributes of layers

Also, are the concept of Pages accounted for by the ordering of parentless layers, or does Acorn not support the notion of pages? Would that be its own table or a modification on the Layer table.

</comment><comment><USER28> OpenEXR solved that problem years ago and it's supported by virtually all content creation tools. An open source implementation with a well designed C++ api and bindings to several other languages.

For reasons that I don't understand, it's adoption is weak outside of the VFX industry.

<comment><USER29> Yeah, OpenEXR (<http://www.openexr.com/>) is a very nice format, well designed and documented, and with an open-source implementation.

Apart from VFX and post-production, OpenEXR has also become the standard file format in HDR applications.

IMHO it isn't mainstream yet because most people don't know what HDR imaging is and why current image formats are inadequate for HDR. For still image editing Photoshop is overwhelming dominant, whereas in VFX pipelines there's a lot of custom tools so you need an open format.

</comment></comment><comment><USER30> Won't this format leave behind traces of what was in the file before? I'm not sure that this is something that we want in a standard interchange format. Users will assume what they are sending is only what they see in an application. This is reasonable. I am concerned that using this format will lead to data leaks.

<comment><USER31> That ship has pretty much sailed with EXIF and embedded metadata anyways, right?

This would seem to be more targeted at digital content creation (and toolchain application interop) than a normal-use file format.

<comment><USER30> It's up to your editor what metadata it chooses to save. It is not up to your editor what data was in the sqlite row that it just modified or deleted but may still be forensically available. There is a fundamental difference here.

It is possible to clean it up of course - perhaps by vacuuming, or definitely by copying to a new file at database level. But it seems dangerous to me to start with a native format with this behavior and attempt to clean it up later.

<comment><USER32> >But it seems dangerous to me to start with a native format with this behavior and attempt to clean it up later.

File formats don't have behaviors. Programs do.

Lots of binary formats, including PNG, will ignore any extra junk after the end of the file. So if a change makes a PNG file smaller, there's nothing stopping a program from leaving data from the old version at the end. But that's not normal behavior for programs that write PNG, so it's not an issue.

As long as programs adopted the behavior of VACUUMing the database, this wouldn't be an issue either.

</comment></comment></comment></comment><comment><USER33> Whats wrong with SVG? Doesn't it accomplish what the OP wants to do already and is already a standard supported by a lot of applications? I must be missing something here

<comment><USER34> XML is a really bad format for containing large chunks of binary data (bitmap)

<comment><USER33> And why are we storing binary data? The whole point of SVG is everything is in XML unless I'm very mistaken

<comment><USER35> How else would you propose to store a bitmap.

<comment><USER36> <points> <point x='2px' y='3px' color='rgba(255,255,255,0)' /> <point x='2px' y='4px' color='rgba(100,255,255,0)' />

        <!--...-->

</points>

heh

</comment></comment></comment></comment></comment><comment><USER37> Zip archive containing an SVG file embedding multiple png/jpg/jpeg2000 images.

</comment><comment><USER31> I would like to suggest this minor change:

      create table layers (id text, parent_id text, sequence integer, uti text, name text, data blob);

become (Vec2 used for notation's sake to make the declaration simpler--just two reals):

      create table layers (id text, parent_id text, sequence integer, uti text, name text, data blob, offset Vec2, bounds Vec2, rotation real);

This would make it really easy to ignore layers which have no component in the view space, or to compactly represent raster subimages.

"bounds" is the size of the axis-aligned bounding-box of the image. "offset" i a translation from the center of the axis-aligned bounding-box of the layer image data to the origin, and "rotation" is the rotation (in radians, CCW) of the layer. Order of application is rotation, then translation.

EDIT: Fixed missing def for "bounds".

<comment><USER11> I think you're missing something in your comment. There's no change between the two lines, and no reference to offset or rotation.

<comment><USER38> mouse over the declaration line and scroll left.

<comment><USER11> Oh, wow. HN really truncates that early. Those code blocks were narrower than the surrounding text, with no indication whatsoever that they were independently scrolling divs.

I get that HN is awfully bare-bones in its appearance, but this I think is a bit too far.

<comment><USER39> That is a problem with _your browser_ not clearly indicating scrollable areas. Hacker News doesn't do anything special to prevent browsers from showing scrollbars.

<comment><USER11> But it doesn't do anything to force the scrollbars either, or to provide a visual treatment that indicates that this is an independent scrollable area. We've had iOS around for 6 years now, with its hidden-scrollbars approach, and OS X has followed the hidden-scrollbars approach for some time now as well. It is no longer acceptable to assume that scrollbars are necessarily going to be visible.

<comment><USER39> Hacker News does everything it is supposed to according to the CSS standard to indicate to your browser that the area is scrollable. In fact, it is obvious that the site is doing enough because the browser does in fact render the area as scrollable. The fact that your browser doesn't do anything to visually indicate when a region is an independent scrollable area is _entirely Apple's fault_.

You can argue that websites should be written to conform to the standards- violating behavior in Apple's browser rather than actual Web standards, but we already went through that with Microsoft in the '90s and early 2000s, and I don't think you'll find a lot of people who are eager to return to those days. Browser-makers are expected to conform to the standard, not vice-versa.

I am sympathetic to the fact that this is inconvenient, because I use Apple's software too. But it's Apple that's responsible for the inconvenience, not all the web designers who are correctly following the standard.

<comment><USER40> Huh. So do we build sites for users or to satisfy specs?

<comment><USER41> Do "we" make browsers to be usable, or to be pretty? If any random hack came up with that idea, it would be a random, hackish idea. But because it's Apple we have to abide? I dare say nahhhh...

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER42> What about OpenRaster? It's used in open source apps like MyPaint and Gimp.

<http://www.freedesktop.org/wiki/Specifications/OpenRaster>

<comment><USER11> > OpenRaster is an open exchange format for layered raster based graphics.

How's that going to work for vector images?

<comment><USER43> You can have SVG layers in OpenRaster. See: [http://freedesktop.org/wiki/Specifications/OpenRaster/Draft/...](http://freedesktop.org/wiki/Specifications/OpenRaster/Draft/LayersStack)

</comment></comment></comment><comment><USER44> One nice thing about using SQLite is that various compressed versions of the flattened image could just be stored as blobs in another table in the same file. For example, my camera shoots with a RAW+JPG mode that produces two files, why not store the RAW data as described here and the JPG as an easy to grab/display item for quick image viewers etc. Hell store various common versions of thumbnails and icons in there as well.

</comment><comment><USER45> This is kind of like saying "We don't need PNG/JPEG/ETC, we just need to put image data in an XML file! It can do everything! Standardization at last!"

Which is true. Except for that little "implementation" detail.

I like the idea of using SQLite as a complex-data-in-single-file format. Hadn't really thought of that for cases like this. But it does _nothing_ to solve the problem of _standardization_.

</comment><comment><USER46> Standardizing a format/API upon a tool like SQLite was something that was proposed in the web world as WebSQL but scrapped due to not wanting an entire standard to rely on a specific code base but rather wanting to have the standard be possible to reimplementable by others and thus creating the IndexedDB standard instead.

I'm not proposing that an image format like this one should use IndexedDB, but if relying on SQLite means being reliant on a specific code base that has to be used by anyone that wants to read the file - then it's probably not such a good idea.

When discussing this I think one should also have in mind eg the move to web apps as well - a reliance on SQLite will make it hard for them to read the format. A standardized simple base format that can easily be supported in new languages would be preferable as I see it - but I'm no expert in the image processing area.

</comment><comment><USER47> > When you want to send someone an image you want to pass them a single file, > not an XML file with a folder of assets. While there are technical benefits > to this, it's an incredible burden on the customer.

Or, you could just zip that whole thing up and everyone who doesn't have to care thinks it is "just one file", like .war's.

<comment><USER34> Other common examples: .app .docx

</comment></comment><comment><USER48> Some of your blobs seem to contain a lot of structured data: I would further specify a format for them somehow: perhaps as further tables that join to the main ones, perhaps as JSON, perhaps as protobufs. Burying application- or format-specific blobs in SQL fields just pushes the problem down a level.

</comment><comment><USER49> The author didn't put the punchline in the title. Why did you put it in the title, HN submitter or editor?

<comment><USER50> On the contrary, in my opinion, this isn't a joke, and since the "punchline" was likely to draw attention to the article from people that might be more interested in a debate over the wisdom of using SQLite "trivially" like this than a generic discussion of image formats, it was useful and shouldn't have been removed from the title.

</comment></comment><comment><USER51> Whatever happened to the debate around how in/efficient the blob storage format in SQLite was? Did that get changed in v3?

EDIT:

Found the official examination[0] on the performance of blob storage.

[0] <http://www.sqlite.org/intern-v-extern-blob.html>

</comment><comment><USER52> Correct me if I am wrong, but FXG files are an archive with an XML file and assets, just as xlsx files are.

How is this a problem? How could is possibly be easier to open a file in sqlite than it is to just extract the file into it's folder structure with any standard decompression software?

I don't know about you, but last time checked there is no easy way to open a file contained in a sqlite database in my editor directly. I for one would much prefer the archive method than using a sqlite database.

Also, I would rather edit xml, than edit a sqlite database. XML can be edited by any text editor. I'd say text editors are a bit more universal and widespread than sqlite editors.

</comment><comment><USER53> And why not TIFF?

<comment><USER54> According to Wikipedia, Adobe Systems holds the copyright to and has control over the TIFF specification.

</comment></comment><comment> mkr-hn Why not XCF?

<https://en.wikipedia.org/wiki/XCF_%28file_format%29>

<comment><USER55> That page says: "The use of XCF as a data interchange format is not recommended by the GIMP developers, since the format reflects the GIMP's internal data structures, and there may be minor format changes in future versions."

<comment> mkr-hn It still seems like a better basis to fork for a format than something new and untested.

<comment><USER56> Something you don't control — and which the people who do control it say "don't use this because we'll probably change it often" — is somehow better than something you _do_ control?

<comment> mkr-hn > _fork_

</comment></comment></comment></comment></comment><comment><USER57> This is an interesting idea, though I cringe a little at using a relational database as a key/value store (as in the case of layer_attributes).

I wonder whether it would be more useful to just represent the whole thing as a big JSON structure with base64 blobs. Each layer can be an object in the "layers" array with the attributes as keys.

<comment><USER58> Layered images can easily grow to gigabytes in size. You do _not_ want to store that much information in a format like JSON that must be opened into memory, parsed and stored in native objects. SQLite is RAM efficient and quick to open, even at large file sizes.

<comment><USER57> Fair enough - I rarely work much with images, so didn't even think of size.

</comment></comment></comment><comment><USER59> What I'd like is the ability for two editors to work on a file at the same time, so layer locks might need to be built in. A db seems to me, a novice in everything relevant(!), to be a good way to allow multiple applications access whilst controlling for collisions.

</comment><comment><USER60> Don't think the discussion is complete without <http://en.wikipedia.org/wiki/OpenRaster> which is already supported in a number of programs.

</comment><comment><USER61> IMHO SQLite is horrible format. using Matroska (.mkv) would be suitable for anything, vectors, bitmaps, audios and so on. It's essentially a container format like XML but for binary

WebM is based on mkv as well.

<comment><USER62> Could you elaborate on what specific benefits using Matroska would have? One downside I can think of is that there are no programming environments (that I can think of) that ship a Matroska parser, whereas sqlite readers/writers are found in many standard libraries.

</comment></comment><comment><USER63> not a huge conspiracy theorist, but isn't this the kind of thing that would make us not rely on purchasing Adobe CS7 exclusively (for fear of incompatability) in the future?

Standards wise, open-source wise, and generally it's a good move (who wouldn't want to get a standard complex image format that would make sense to the common programmer?), but I don't think the finance department over at Adobe is going to like it very much?

</comment><comment><USER64> .ora? (OpenRaster)

<http://en.wikipedia.org/wiki/OpenRaster>

gimp (plugin), krita, and mypaint

</comment><comment><USER65> If someone does this right, it should go over pretty well for EDA (Electronics Design) file formats. EDA is a wasteland.

</comment><comment><USER66> Good luck opening and modifying that 150MB psd file.

</comment><comment><USER67> xkcd.com/927 :)

</comment><comment><USER68> A limited subset of HTML would be nice.

</comment><comment><USER69> How about an additional frames table?

</comment><comment><USER70> this is like saying "i've invented a standard file format for all types of files. i call it binary. it's made up of zeroes and ones. i've solved interoperability forever".

</comment><comment><USER71> Amen!</comment>


Indian phone vendors to release $30 Android Oreo Go smartphones this month on - <AUTHOR> https://factordaily.com/india-30-android-oreo-go-smartphones/ <comment><USER2> What's in it for the manufacturers? The wafer-thin margins on this means that companies will have to figure out other forms of business model innovation, such as selling user data.</comment>