Live data from Hacker News

UsesThis: Rob Pike

rob.pike.usesthis.com

181–190 of 192 posts

Re: UsesThis: Rob Pike

#181
post #173

Earlier quoted context omitted.

Ah, that's why in LaLa Land, all our apps save automatically and everything is version controlled.

In OSX Lion, Apple released Auto Save and Versions, which does exactly this. Except that just a tiny amount of applications I use in my daily development life does this. But in casual use, it's actually quite nice. If the application implements the whole set of Lion auto saving / state API's, you don't even have to save the files for them to remain available. I can write on multiple unsaved documents with TextEdit, c…

I'm envisioning a new OS where this is built into not only the file system, but the APIs that apps use to interact with it. So all the (brand new!) apps work in the system.

Re: UsesThis: Rob Pike

#182
post #157

Earlier quoted context omitted.

True ROM chips are by definition available in sizes slightly larger than similarly priced DRAM or SLC flash, it's probably cheapest memory to manufacture. And you would be surprised about how many megabytes of ROM are contained in Android/iOS devices (baseband code is often i mask ROM on chip, modern SoCs tend to have some kind of support core with code in mask ROM and also some ARM acessible mask ROM with things lik…

So who makes, say, 4GB E(E)PROM chips? I'm thinking Windows here, not Android. Clearly the technology isn't the problem but the largest ROMs I've worked with are all in the Mbit range.

I don't think these are widely available ... Practical solutions for Windows would probably be DVD-ROMs or read-only NAS filesystems, or (for reasonable speed) SSDs, preferably PCIe or Mini-PCIe with hardware write-protect switch.

Re: UsesThis: Rob Pike

#183
I'm hesitant to move to the cloud until privacy issues are fundamentally addressed. All these vendors pouring over user data is not in our interest. I think it will take laws and government action to stop this sort of privacy invasion. Until that happens, I'll keep my local storage.

Re: UsesThis: Rob Pike

#184
post #48

The whole "everything in the cloud", "let someone else worry about storage" view, at least the way he promotes them, are more like VCS than let's say Git (or pick another DVCS)... you have a conceptual "central" point of failure, even if this "point" is a network of servers distributed around the world. I want STORAGE ON EVERY DEVICE (not volatile!), and and automatic system to sync it with all my other devices, WITH…

The hard thing about his vision, is safety.

Carrying the cellphone means two things: The state data is available with you (it's not in the cloud) and the actual hardware is your authentication token for the things that are in the cloud.

In his vision he talks about having state and everything in the cloud, login in from any terminal and doing his job.

He would go to a coffee/Internet shop and do all his personal banking there. It should be obvious at this point the problems that could arise from such setup.

The terminal could be compromised (key loggers, etc), and no authentication tokens have been defined. Even retina scanners are more troublesome than having a cellphone as the auth token.

So his vision is nice, in an ideal society where no one cheats, ever.

In the real world it is dangerously unsafe.

> DVCS should be the models for how to do everything in the cloud, with simpler interfaces for different level of user needs/competency.

I still dream about a Git GUI that works as a distributed Dropbox (for some specially enabled repos, not for all of them).

Re: UsesThis: Rob Pike

#185
post #184
post #48

The whole "everything in the cloud", "let someone else worry about storage" view, at least the way he promotes them, are more like VCS than let's say Git (or pick another DVCS)... you have a conceptual "central" point of failure, even if this "point" is a network of servers distributed around the world. I want STORAGE ON EVERY DEVICE (not volatile!), and and automatic system to sync it with all my other devices, WITH…

The hard thing about his vision, is safety. Carrying the cellphone means two things: The state data is available with you (it's not in the cloud) and the actual hardware is your authentication token for the things that are in the cloud. In his vision he talks about having state and everything in the cloud, login in from any terminal and doing his job. He would go to a coffee/Internet shop and do all his personal bank…

> I still dream about a Git GUI that works as a distributed Dropbox (for some specially enabled repos, not for all of them).

Please look above in this thread about git-annex if you haven't heard of it. That's.. pretty much exactly what it is.

Re: UsesThis: Rob Pike

#186
post #184
post #48

The whole "everything in the cloud", "let someone else worry about storage" view, at least the way he promotes them, are more like VCS than let's say Git (or pick another DVCS)... you have a conceptual "central" point of failure, even if this "point" is a network of servers distributed around the world. I want STORAGE ON EVERY DEVICE (not volatile!), and and automatic system to sync it with all my other devices, WITH…

The hard thing about his vision, is safety. Carrying the cellphone means two things: The state data is available with you (it's not in the cloud) and the actual hardware is your authentication token for the things that are in the cloud. In his vision he talks about having state and everything in the cloud, login in from any terminal and doing his job. He would go to a coffee/Internet shop and do all his personal bank…

> I still dream about a Git GUI that works as a distributed Dropbox (for some specially enabled repos, not for all of them).

Please look above in this thread about git-annex if you haven't heard of it. That's.. pretty much exactly what it is.

Re: UsesThis: Rob Pike

#187
post #184
post #48

The whole "everything in the cloud", "let someone else worry about storage" view, at least the way he promotes them, are more like VCS than let's say Git (or pick another DVCS)... you have a conceptual "central" point of failure, even if this "point" is a network of servers distributed around the world. I want STORAGE ON EVERY DEVICE (not volatile!), and and automatic system to sync it with all my other devices, WITH…

The hard thing about his vision, is safety. Carrying the cellphone means two things: The state data is available with you (it's not in the cloud) and the actual hardware is your authentication token for the things that are in the cloud. In his vision he talks about having state and everything in the cloud, login in from any terminal and doing his job. He would go to a coffee/Internet shop and do all his personal bank…

Maybe you're dreaming of http://sparkleshare.org/

Re: UsesThis: Rob Pike

#188
post #138
post #66

Earlier quoted context omitted.

The mousing is what lost me. I love vim because you don't have to deal with the mouse at all.

The mousing is what adds a crazy amount of power. You end up with dozens of files on screen, some showing text, some just displayed as the "tag" line. You use the mouse to rapidly jump around them, select text from one, paste into another, etc. The mouse is a pointing device, why not use it to point at things? If I have 3 columns in my acme window (which I usually do) and I'm working in the 3rd file down in the left-…

You make a good case for acme; I'd be willing to try it. But I'm not convinced that in any context grabbing the mouse (with or without chording) is faster than keying, esp. since in vim many of the most important navigational keys are on the home row.

Re: UsesThis: Rob Pike

#189
post #138
post #66

Earlier quoted context omitted.

The mousing is what lost me. I love vim because you don't have to deal with the mouse at all.

The mousing is what adds a crazy amount of power. You end up with dozens of files on screen, some showing text, some just displayed as the "tag" line. You use the mouse to rapidly jump around them, select text from one, paste into another, etc. The mouse is a pointing device, why not use it to point at things? If I have 3 columns in my acme window (which I usually do) and I'm working in the 3rd file down in the left-…

[deleted]

Re: UsesThis: Rob Pike

#190
post #188
post #138

Earlier quoted context omitted.

The mousing is what adds a crazy amount of power. You end up with dozens of files on screen, some showing text, some just displayed as the "tag" line. You use the mouse to rapidly jump around them, select text from one, paste into another, etc. The mouse is a pointing device, why not use it to point at things? If I have 3 columns in my acme window (which I usually do) and I'm working in the 3rd file down in the left-…

You make a good case for acme; I'd be willing to try it. But I'm not convinced that in any context grabbing the mouse (with or without chording) is faster than keying, esp. since in vim many of the most important navigational keys are on the home row.

You really need to try it, if nothing else it will broaden your experience so you can compare vi vs. emacs vs. acme. Myself, I watch vim users spend so much time just trying to get their cursors to the appropriate part of the file/line, and then select the appropriate text, that I scratch my head--this is faster? By the time you've figured out that typing "/whatev" should be sufficient to get you to the point you want, I could have grabbed the mouse, simply pointed it to the location I'm interested, and had my hands back on the keyboard already. Don't get me wrong, I also use vi a lot because it's very convenient and very powerful, but there are some things I'm much happier with in Acme.
Post reply on HN