richardjs

If you'd like to improve, definitely! There are all sorts of things involved in singing that some do naturally and others (like myself) do not. Having a knowledgeable teacher who's able to observe you, identify areas of improvement, and help you progress is really beneficial. There's a whole lot of "not knowing what you don't know" at play.

Plus singing is a pretty personal way of making music, and there can be a lot of social fear of doing it badly. Formally studying it can help with getting over the psychological hump from self-identifying as "someone who is attempting to sing" to "singer".

Under $1000:

Voice lessons at the local community school of music. I'm a lifelong musician, but was an almost entirely solitary one. I taught myself different instruments, but I never felt like I could get to basic competency teaching myself to sing. I decided to spend ~$200 for a semester of weekly 30 minute lessons. (The community school cooperates with the local university to offer lessons taught by university students for a low rate.)

My singing improved (more work is needed), but the life-changing thing was getting involved with the local music community. It turns out they have a shortage of piano teachers--I had mistakenly assumed there would be plenty in my town! So I started teaching piano, which had long been a dream of mine. The school also connected me to local performance opportunities that are now a part of my regular music routine. And ultimately, the experience encouraged me to enroll as a (part-time) music student at the university, which itself has been extremely enriching and a tremendously positive community experience.

Standard Ebooks also has an edition: https://standardebooks.org/ebooks/p-t-barnum/the-humbugs-of-...

Dagnabbit!

Thanks for pointing that out. Would edit if I could.

Standard Ebooks does modernize language; it's step 14 on the production guide[1].

[1] https://standardebooks.org/contribute/producing-an-ebook-ste...

I was a heavy Google Reader user and mourned it for years. At some point, though, I discovered Miniflux [1], and haven't really missed Reader since.

What I do miss from the Reader days, though, is widespread RSS support. I wonder if the death of such a prominent RSS reader gave sites "permission" to stop supporting RSS, and pushed RSS into further obscurity. Anecdotally, it feels like RSS is a feature often not carried over after a site redesign.

[1] https://miniflux.app/

It's not Escape Velocity, but Maelstrom was open-sourced [1]!

A while ago I forked a version and changed the braking power-up to be controlled by a button press, instead of always active [2]. It was cool to fix something that always bugged me in a game I played when I was a kid.

[1] https://en.wikipedia.org/wiki/Maelstrom_(1992_video_game)#Le...

[2] https://github.com/richardjs/maelstrom

It looks like the subject has come up a couple times on the mailing list [1] [2], but in my (admittedly casual) searching I didn't find anything since 2017, with the most relevant answer being "not at the moment". Since it has been a couple years, maybe it's worth bringing up again on the mailing list?

[1] https://groups.google.com/u/1/g/standardebooks/c/JdVpCm3ckGg...

[2] https://groups.google.com/g/standardebooks/c/osOEfs5HdLo/m/2...

Accepting that we're just throwing out interesting-sounding ideas, I wonder if having a powered runway rail (or something of the sort) to provide takeoff power could work. With that you wouldn't have to worry about dropping anything.

But I do wonder how much power is actually expended at takeoff versus climbing or cruising flight. According to [1], only ~19% is used for both takeoff and climb, so electrifying the runway to save the fraction of the 19% used while in contact with the ground is probably not worth it.

[1] https://aviation.stackexchange.com/questions/47262/how-much-...

Wacom also sells drawing tablets with integrated displays [1]. I've never used them or an Apple Pencil, so I don't know how they compare, but Wacom isn't totally caught out here.

On the other hand, I can see a lot of people buying (or already owning) iPad Pros and using this feature who might not buy a dedicated device for it.

[1] https://www.wacom.com/en-us/products/pen-displays

People do. That's what the pledge drives and "brought to you by viewers like you" commonly heard on PBS are about.

Different local stations rely on difference funding sources. Stations in smaller or rural markets would have a harder time existing on direct donations alone.

PBS has underwriting spots that are only shown between programs and are subject to more restrictions than commercials: https://en.wikipedia.org/wiki/Underwriting_spot

No programming is interrupted, and the only marketing content is typically something like "Brand Flakes is happy to support PBS".

I glossed over it a bit in my first post, but the data on the drive is actually always encrypted. The system decrypts the data on the fly as it's read into memory, and encrypts when it writes to disk again. This has less of a performance impact than you'd think.

Also, just to be explicit on the user experience: when you boot the machine, one of the first things the kernel does is ask for a decryption password. If you cannot provide that, the system cannot boot further, because everything but the kernel and bootloader (in /boot) is behind the encryption.

1) So as described above, the storage is always secure, regardless of whether the machine is on or not. The rub is that when the machine is in use, the system is actively performing this decryption/encryption. I'm not an expert on the technical side of it (and it probably differs between implementations), but I'd imagine the OS keeps the decryption key in memory. This is functionally an instance of the "it's got to be decrypted sometime" problem, or a variation of the "analog hole" in DRM. At some point, the user will be accessing a decrypted version of the data, and if the attacker is able to take control at that point, he obtains the data.

Let's say I have an encrypted text file (on an unencrypted, regular system setup). To write to or read the file, I need to decrypt it. Maybe a program takes a password and opens a text editing window with the decrypted data. If I care about the security of that data, I'm not going to leave that window open unless I'm actively using it. I understand that if I leave that window open and someone walks by my machine, they'll be able to see the contents, because I left the data in an decrypted state. But I need to have that window open sometime, because I need access to the file myself. It's the same situation with full disk encryption--at some point the data will be decrypted for legitimate use (in FDE's case, only in memory, but still decrypted), and it's up to the user to protect it during those times.

If you lock your machine (using xscreensaver, slock, etc.) and set it to lock when waking from sleep (and whenever else), the attacker must circumvent the lock program before he can access the machine. Ideally this would not be possible (a lock program that lets someone access the system without the password is not a great lock), but there's always the possibility of some vulnerability.

Alternatively, you can always hibernate your machine instead of sleeping it. Hibernate writes the contents of memory to disk and shuts the machine off. When booted back up, the kernel finds the hibernated memory and seamlessly resumes from where you left off. If you set it up properly, the system will write the hibernated memory to an encrypted partition, so the session cannot be resumed without the encryption key. The downside is you have to type the encryption key every time you resume, and my encryption password is a good deal longer than my normal user account password.

In my own practice, if I'm leaving my laptop at a place I'm more worried about theft, I'll hibernate it. In normal use, I'll sleep it and rely on the lock program. Like I said in the earlier post, though, I'd love to hear if anyone has a better approach, or even an analysis of the security of some common lock programs.

2) I have no direct experience with SEDs, but I'm under the impression they decrypt the entire drive when powered on and the password is entered. Or else, they do the same on-the-fly operations I described above. As such, they would be vulnerable to the same attacks as above. Their advantage is transparency to the operating system and better performance. Also see Wikipedia's description of some of their vulnerabilities: https://en.wikipedia.org/wiki/Hardware-based_full_disk_encry...

3) FDE essentially answers the "how to efficiently enter credentials" question with "at the start, when you first mount the partition" ;). Aside from that, file-level encryption solutions definitely exist, and are commonly used. You can encrypt arbitrary files with the openssl command, and many sensitive files (such as SSH keys) have encryption built into their standard usage (SSH key passphrases). Even when running FDE, I keep a passphrase on my SSH keys, because there's nothing stopping a rogue program from grabbing them during normal computer use. I'd encourage any other extremely sensitive files to have their own protection. To quote tptacek, "FDE does basically one thing for you: it reassures you if your laptop is stolen from the back seat of your car or left in a cab." [1]. Other steps need to be taken to run a secure system.

However, I don't know of a file-level encryption solution that functions exactly as you describe. It would be tricky to implement, for the reasons you described, and others. For example, background programs write to the disk too, and sometimes what they write contains sensitive data. Are you going to enter the key periodically for their use too? And will all these programs play nice with the (comparatively) huge blocking times when writing while you type in the key?

4) Of course, that's the question with any security solution. Many of the Linux solutions are open source, so that's at least a plus, but certainly not any guarantee of security. Short of being a security professional capable of auditing the complete source, you have to rely on project reputation, recommendation, and (ideally) someone else's audit. I'm sure lots of people would like a better answer to this question!

Hope that all helps!

[1] https://news.ycombinator.com/item?id=9069669

Sorry for your experience.

One standard approach is to set up full disk encryption. A common setup would encrypt every partitions but your /boot partition, so a thief would be unable to access your system if it were powered off. (If you're especially cautious, you can do tricks to protect your /boot partition too, to guard against tampering, but that's beyond the scope of protecting against theft.)

The catch is if the thief steals your powered-on laptop, the system's still decrypted (meaning, the decryption key is still in memory). I'd guess locking your machine is a partial guard (and is what I rely on), but I'd be interested in learning if there's a better method of protection.

ArchWiki has a pretty good overview: https://wiki.archlinux.org/index.php/Disk_encryption. I'm happy to try and answer any questions you have.

What's your source for that? The CDC estimates 1 in 6 people a year get sick from food eaten in the US, and I can't imagine that none of that food is from a modern supermarket. Poultry, for example, "often contains harmful bacteria such as Salmonella and Campylobacter." [1]

That said, it's not hard to cook food safely. The USDA publishes guidelines [2], which you can then adjust with your own experience and research. (The guidelines are just guidelines, and lack nuance. For example, chicken cooked lower than 165 can still be safe, but takes longer to pasteurize. [3])

Of course, despite all this, cooking isn't a high-risk activity. People everywhere of mixed (or lax) skills and safety have been doing it for thousands of years, and yet foodborne illness is not mankind's single greatest existential threat.

[1] https://www.cdc.gov/foodborneburden/attribution/attribution-...

[2] https://www.fsis.usda.gov/wps/portal/fsis/topics/food-safety...

[3] http://www.seriouseats.com/2015/07/the-food-lab-complete-gui...

Van Gogh is most known for his painting, but he also created drawings. For example, he drew a pen and ink version of Starry Night [1]. I particularly like Windmills at Montmartre [2]. I think it'd be easy to argue his talent and skill carry over into his drawing.

I say all this to quote him writing to his brother: "I cannot tell you how happy I am that I have taken up drawing again. I had been thinking about it for a long time, but always considered it impossible and beyond my abilities." [3]

[1] http://www.vangoghgallery.com/catalog/Drawing/1574/Starry-Ni...

[2] http://www.vangoghgallery.com/catalog/Drawing/1729/Windmills...

[3] http://www.vangoghgallery.com/drawings/

Any user can become a developer if he or she chooses. The user may decide it requires too much work to learn to code in order to implement a given change, but the option is there nonetheless.

At least they're not as dangerous as pool halls.

Are you thinking of sleet? Hail is associated with severe thunderstorms,[1] which definitely occur in areas with mosquito populations.

[1] http://www.accuweather.com/en/features/trend/hail-or-sleet-h...

I'm a little confused about the issue. I understand the problems you have with the reprompt option, and if that causes you to switch from LastPass, it's your decision.

But could this issue be solved by keeping your computer locked when you're not using it? I understand that might not fit your general computer usage, but it's how I use LastPass, and I certainly wouldn't use the service without locking my machine (reprompt enabled or otherwise--reprompt is turned off for most of my passwords).

You also mention trying very fast autologout policies, but that it gets annoying to have to enter your password twice. My question is, if you're logging out immediately, why do you need the reprompt option enabled at all? If a user can log in, they can certainly reenter the password, so the only thing the reprompt does is annoy you, with no added security.

I don't know your particular computer use, though, so forgive me if what I'm saying isn't applicable.

But not enough to buy a smaller, more durable phone? One with a thick, rubber or plastic exterior case? No? I didn't think so.

I only just recently upgraded from an old feature phone to a Moto G. One of the major reasons I selected it was its relative cost versus other phones, and thus less worrying on my part about it (also, it was the cheapest phone Republic Wireless was offering). While that's not specifically buying based on durability, it's the same idea of being concerned about how much money you've sunk versus how easily it will break.

Even still, I don't go sitting on it (or, if I discover I'm sitting on it, I immediately cease the sitting action). I'm not arguing Apple should refund these people for their bent phones or anything, and I agree that people should take personal responsibility for their actions. I'm just fine with the potential lack of durability being discussed, which is the issue stevewepay originally mentioned.

EDIT: Upon further thinking, I agree that my comparison to "you're holding it wrong" is somewhat mistaken. While the grip one uses on a phone doesn't have any common-sense effects, putting a phone in your back pocket and sitting on it should have clear potential consequences, even if phones of the past typically had the durability to withstand it.

When did durability stop being a factor used to assess a phone's quality? As someone who is somewhat accident prone (and who doesn't want to spend too much time fretting about protecting my phone), it's something I care about.

Granted, I don't this should be as big of an issue as some people are making it out to be, but I think the discussion should go beyond chastising owners for putting their phones in the wrong pocket. That's not much better than saying "you're holding it wrong."

If the back pocket is "not supported", that's fine, but when support is pulled on anything that people use, (however obscure or unwise its use may be), there's going to be friction.

Get a license with something like ASCAP[1]. I think that's what most businesses using music in a public setting do.

Legally using copyrighted music is not exactly an impossible task. I mean, it's basically the entire business of some radio stations, and some stations are quite small.

Now, is it worth the effort and cost for a Twitch stream? It depends on how much value the music brings. There's also CC or royalty-free music, if a streamer just wants some music playing.

[1] http://www.ascap.com/licensing/licensefinder

That's a good suggestion. Yeah, index directives will cause a redirect loop in my above configuration. The try_files directive is effectively taking the place of an index.

Your specs look a lot like ours (we have a CMS that adds a trailing /index to every page that is part of the core navigation, and we don't want that). Here's the three primary rewrite rules we use for the issue; they don't match your spec exactly, but they might help you get started:

    # - Remove trailing slashes (except root /)
    # e.g. /foo/bar/ -> /foo/bar
    # ([^^] matches every character but the start of the string)
    rewrite [^^](.*)/$ /$1 permanent;
     
    # - Remove .html and .htm extensions
    # e.g. /foo/bar.htm -> /foo/bar
    rewrite ^(.*)\.html?$ $1 permanent;
     
    # - Remove index file URLs
    # e.g. /foo/bar/index -> /foo/bar/
    # (the trailing slash is then removed by the first rewrite)
    rewrite ^(.*/)index$ $1 permanent;

    # Try the request URI, and a potential index file in the URI (in the case of a directory).
    # This lets you hit the file WEBROOT/foo/bar/index with the URI /foo/bar,
    # and hit the file WEBROOT/foo/bar.html with the URI /foo/bar
    try_files $uri $uri/index $uri.html =404;

    # You need this (or some other way to provide the type information)
    # if you don't have extensions on your files.
    default_type text/html;

    error_page 404 403 /404; # The .html in your spec will be stripped off by the above rewrite rule

It's also mentioned on his blog, or at least the statement "I’ve resigned as CEO and I’m leaving Mozilla to take a rest..." [1]. Doesn't explicitly say he's never coming back, but certainly says he's leaving Mozilla for a time.

[1] https://brendaneich.com/2014/04/the-next-mission/

Link to the paper: https://jscholarship.library.jhu.edu/bitstream/handle/1774.2...

The paper says it targets older iSight cameras, found in models until 2008. Anyone know if modern cameras better protection?

Also, fix the copyright line at the bottom, unless the company's name really is "Your Company". And the privacy policy "link" isn't a link.

In other news, I'm seriously craving salsa now, so that aspect of the site works.

There is an automated backup system that you have to enable for a droplet, that creates a snapshot every few days. It's a clear part of a droplet's control panel. They began charging for it in July 2013. The price is 20% of the droplet's monthly cost. Sounds like they need to update their pricing page.

This is pertaining to a droplet feature though, and not some low-level backup system. Meaning, it's not as if they're lying about the infrastructure below what a normal customer can see. They just have an erroneous pricing page.

By the way, am I not, accidentally, at a site called "Hacker News"?

The parent's point wasn't that Apple was trying to lock out the standard HN reader, or that an HN reader shouldn't try to repair the device. His point was that Apple is putting an obstacle in the way of a nontechnical person shooting themselves in the foot.

The clock thing above isn't a fair comparison, a computer doesn't fall apart into two hundred pieces once you unscrew the case

I think it's a good comparison. As the grandparent mentions as an example, removing the battery risks slicing the trackpad I/O cable. While that's not falling apart into hundreds of pieces, it certainly hinders use of the computer.