Want to use my wifi? - <AUTHOR> http://thejh.net/written-stuff/want-to-use-my-wifi? <comment><USER2> Using a browser in incognito mode does none of the sort. You can still enter your password into it and it can be stolen just as easily. The true solution is to only browse over HTTPS, connect to a VPN or not use untrusted networks.

Note that if I can spoof an IP address, I can send you bogus DNS replies, and send you to a web server that impersonates Google/Facebook/etc. but does not require HTTPS (unless they use the strict security header). In this case you do not get a warning, just the absence of a tiny green icon.

<comment><USER3> How easy is it to fully automate VPN only computer usage so that everything I do comes out of a machine at Amazon EC2 for example?

I've never set it up and was curious what others have done to make it as invisible as possible.

<comment><USER4> _How easy is it to fully automate VPN only computer usage so that everything I do comes out of a machine at Amazon EC2 for example?_

Startup idea! Make a tool that automatically tunnels your connection when you are on a public wifi. Make it open source and offer a hosted service. Also interesting if you are in a country which censors the internet. The dropbox of VPNs. For marketing you offer to write articles like this but less technical for magazines ("on Page 10 learn how easy it is for hackers to steal your facebook account and how you can protect yourself").

<comment><USER5> There are a multitude of VPN services in the market already. The generally accepted "best practice" for those with VPN service is to use it everywhere (not just on the road). When you're paying monthly, most people feel incentivized to use the service as much as possible.

I've set up VyprVPN for a couple of ultra-paranoid friends, and the whole process was very smooth and end-user friendly.

<comment><USER4> And there were plenty back-up services before dropbox.

<comment><USER5> I get what you're saying, but Dropbox is not a back-up service. The distinction is that Dropbox didn't exist before Dropbox. There are unique aspects of Dropbox that were _new_ when Dropbox was introduced.

There is nothing new or unique in what you described, with the exception (maybe) of automatic initiation of VPN services when you're on "public" wifi. I would argue that this is a differentiation of little or no consequence, because there's no reason to _not_ use a VPN all the time.

You basically described every personal VPN provider in the market as a start- up idea.

</comment></comment></comment></comment></comment></comment><comment><USER3> Is it possible to use the browser in https only mode, or at least have it force launch any https sites in a new incognito mode window so that you know it's http-only. Furthermore, it would be nice if you could disable all text inputs on http-only windows.

I know that I would be more likely to contact a site owner asking for https if it screamed at me everytime it happened.

It's time to ditch http for all but rare use cases, because almost 2014.

<comment><USER6> Get the "HTTPS Everywhere" addon for Firefox, or, apparently, Chrome now.

<comment><USER7> that "only" uses a list of known https domains to force the browser to use them. It does not magically enable "https everywhere".

</comment></comment></comment><comment><USER8> Just for teh lulz, you could do ARP-spoofing on public wifi's too, and achieve the same effect wthout having the trouble of setting up a hotspot.

I admit of having spoofed a Burger King public WiFi and replacing all img-tag sources with Goatse. Priceless reactions everywhere ;)

<comment><USER9> I like BT OpenZone in the UK. It seems everyone has connected to one of these at some point so you just create an ad hoc wireless connection with the same SSID and most modern smartphones automatically connect and start trying to download mail and facebook updates.

</comment></comment><comment><USER10> I've been thinking about the possibility of injecting a JavaScript bitcoin miner into every page loaded through my access point. Imagine the possibilities for an open AP that's located in a very public place, like Times Square, or near a busy Starbucks (where access is slow and unreliable).

If you really wanted to take this to the evil next level, you'd just break one (or several) WPA keys on nearby APs and have your rouge injector AP act as both an open AP (to unsuspecting users) and a client (using cracked keys) to other APs, thus avoiding having to actually buy internet access for this spot. You'd essentially just need to find a place to hide and power your evil AP.

<comment><USER11> Is that even remotely lucrative? As I understand, even a $300 GPU is orders of magnitude more powerful than any CPU miner, let alone a JavaScript based one. And even a single GPU isn't remotely competitive these days compared to the GPU farms and now ASIC setups. So you'd need to inject JS into, I dunno, a million, devices to make anything worthwhile.

<comment><USER12> You could probably use WebCL, Flash or Silverlight to use the user's GPU. A quick Google shows this has been done with WebCL already: [http://webcl.nokiaresearch.com/jsoclbm/](http://webcl.nokiaresearch.com/jsoclbm/)

<comment><USER11> There's a neat hardware comparison here: [https://en.bitcoin.it/wiki/Mining_hardware_comparison](https://en.bitcoin.it/wiki/Mining_hardware_comparison)

Seems like ASICs are measured in the thousands to tens or hundreds of thousands of MHashes/sec. Whereas powerful GPUs drawing ~1000 Watts don't even break 1000MH/sec. High-end laptop GPUs seem to be in the 10s of MH/sec, a quad-core Atom shows 2MH/sec, and the Galaxy SII comes in at 1.3.

The vast majority of devices connecting to public APs are not going to be high-power systems. Not to mention the time they'll spend connected is unlikely to be 24/7\. Even if it was, mining will probably drain batteries pretty quickly. Plus power-saving is likely to be on for mobile devices and reduce peak perf. And if it's just injecting JS, then backgrounded tabs should get much less CPU time. And WebGL/etc. are unlikely to be running in background tabs.

If you assume a device stays connected and open for 1/4 a day, and stays for 3 days on average, and gives you 1MH/sec (seems optimistic, all things considered), 1 million devices compromised a month gives you ~$300 a month. If the assumption is that you can persistently own a machine, then you'd need less machines. But that's going beyond simple JS injection on HTML pages.

I used this calculator: [http://www.alloscomp.com/bitcoin/calculator](http://www.alloscomp.com/bitcoin/calculator)

</comment></comment></comment></comment><comment><USER13> Inject something like XSS Tunnel ([http://labs.portcullis.co.uk/download/XSS- Tunnelling.pdf](http://labs.portcullis.co.uk/download/XSS-Tunnelling.pdf) that gives you a local proxy that you can point your local browser and then sends all of your traffic through the victim, so you'll see and use the website(s) with your victim's session), or BeeF - [http://beefproject.com/](http://beefproject.com/) for tons of exotic XSS based exploits.

</comment><comment><USER14> These attacks could be given longevity by using a cache manifest.

</comment><comment><USER15> Situations like these are how I justify keeping a low power 24/7 box on at home. In situations where I don't have my own (trusted) connection, I'll just ssh tunnel a SOCKS5 proxy to my home server. I only have a residential internet connection at home, but 2mbps is surprisingly snappy for casual or emergency on the go web browsing. With boxes out there (e.g. rPi) that push power consumption far south of 10W, it makes even more sense to do this now.

Of course, it also doubles as an IRC idler/whatever else you can think of.

<comment><USER16> Yep, I have a Dreamplug with dual ethernet and an attached USB hard drive. Last I checked, the hard drive used more power than the machine itself.

SSH is done through key authentication and there's an OpenVPN server if the network I'm connecting through isn't too locked down.

Next trick is to do IP-over-DNS and I'll be all set where ever I am.

Now if only someone would come out with a USB3-capable board with dual-gigE (I don't mind if it can only push 500Mbit each port)

<comment><USER17> _Next trick is to do IP-over-DNS and I 'll be all set where ever I am._

iodine[1] is a fairly easy way to set that up. I just made a tunnel.mydomain.tld subdomain, pointed the NS records at my VPS and run "iodined 10.0.0.1 tunnel.mydomain.tld"

[1] [http://code.kryo.se/iodine/](http://code.kryo.se/iodine/)

</comment></comment></comment><comment><USER18> Using a VPN would protect you against all of this right?

<comment><USER19> Assuming you can trust the VPN and the encryption is good it should.

</comment></comment><comment><USER20> I wonder if this attack would also work on the [http://www.gstatic.com/generate_204](http://www.gstatic.com/generate_204) page that Chrome uses to detect captive portals if you are accessing https pages.

</comment><comment><USER21> Has anyone tried ICMP tunnels?

</comment><comment><USER22> It's pretty easy to set up a VPN on EC2. Probably not the BEST solution out there (the instances certainly aren't designed for that use) but better than nothing.

<comment><USER23> At $0.07/hour for 1TB/month, with <1min startup time, DigitalOcean is actually a decent host to do this with.

</comment></comment><comment><USER24> > Commandline snippet poisoning

Really? So would you blindly copy-paste things into your shell? Then I don't need to hijack your connections, I just put malicious pastes on the website.

If you are moron enough to copy-paste the first thing you find, you are probably not reading the other users' warnings about "this answer is wrong".

<comment><USER25> The attack mentioned is to change the text when you go to copy it; that will get even people who carefully read every forum post before copying and pasting.

How many people review the snippet, copy, paste it into a text editor, _re_ -review it, copy it, and then paste it into their shell?

<comment><USER26> Ctrl-X Ctrl-E in bash will open an editor for the current command, which is executed when the editor is exited. After the potential for exploit was publicised a few months ago, I use this every time and it's really not much more effort than just pasting into the shell. As a bonus, it means I don't have to worry about embedded newlines stopping me from tweaking the command before running it.

<comment><AUTHOR> You can embed \x1b (escape) into a webpage. When you copy-and-paste that, it has the same effect as hitting ESC in the editor. So, I'd just have to make you copy "<evil command>#\x1b:wq\n" to also catch the case that you're using vim instead of directly pasting. However, I can't figure out a way to escape from nano.

(Tested it with the combination chromium+xterm+vim.)</comment></comment></comment></comment>


How the Rich Get Richer, Rental Edition - <AUTHOR> http://www.nytimes.com/2012/02/17/us/san-francisco-rent-control-and-unintended-consequences.html?_r=2&

<comment><AUTHOR> "Mr. Karnilowicz estimated that 5 percent of the city's (San Francisco) 212,000 rental units (about 10,600) are kept vacant by landlords who would rather not deal with rent control (others estimate the number is higher, about 25,000 units). He said that many owners would rent those homes if there were reforms, like requiring the rich to pay full market value."</comment>


Why Teams Will Defeat Slack in the Long Run - <AUTHOR> https://curiosum.dev/blog/slack_vs_teams_who_wins <comment><AUTHOR> Collaboration software is present almost in every business, in one form or another. The one that first comes to mind and was in many ways a precursor of the field – Slack – has found more and more capable rivals with every passing year. However, now in 2020, Teams by Microsoft seems like it will lead the pack for a while.

<comment><USER2> Slack is ~60 years too late to be a precursor of the field.

[https://en.wikipedia.org/wiki/Collaborative_software](https://en.wikipedia.org/wiki/Collaborative_software)

</comment></comment><comment><USER3> Like Skype defeated Zoom?</comment>


Linus Torvalds Admits He's Been Asked To Insert Backdoor Into Linux  - <AUTHOR> http://www.eweek.com/developer/linus-torvalds-talks-linux-development-at-linuxcon.html

<comment><USER2> Seems like it was meant as a joke ...

<comment><USER3> From Ars Technica's article on Linus' talk at LinuxCon:

> A couple of final notes: The panelists were asked if they've been approached > by the US government to insert a back door into the Linux kernel. Torvalds > said no while nodding his head, drawing a laugh.

[http://arstechnica.com/information- technology/2013/09/linus-...](http://arstechnica.com/information- technology/2013/09/linus-torvalds-worries-about-how-linux-will-handle-the-end- of-moores-law/)

Very clearly a joke. This is total linkbait crap.</comment></comment>


Vote up if you think there should be a video section - <AUTHOR>

<comment><USER2> Please use the request thread for future requests. There has only been a couple video submissions in the last few days; why create a page for those?

<comment><AUTHOR> Thanks for your feedback and ideas, guys! To answer your question, there were actually 7 video submissions in the past 24 hours between Google and YouTube alone. Had I known you were interested in videos, I would have e-mailed them to you so you wouldn't miss them.

Had there been a video section, nobody would have thought there were only 2 videos submitted in the past few days.

Please let me know if you have any other questions!</comment></comment>


A Perfect Example of How Steve Jobs' Health Issues Are Exploited - <AUTHOR> http://www.macblogz.com/2009/01/27/a-perfect-example-of-how-steve-jobs-health-issues-are-exploited/

<comment><USER2> _at a certain point, prying into the man's private life and reporting about a rumored surgery becomes a tad questionable_

It was valleywag who reported this; the website whose entire _purpose_ is to exploit and intrude into the private lives of others. The only way to stop the behavior of sites like valleywag is for people to stop visiting them, and for major sites to stop blogging about every controversial post they make. Sadly, that's probably never going to happen.</comment>


Ask HN: How is the Y Combinator UBI experiment going? - <AUTHOR> I haven't heard anything about the YCombinator UBI study in a while - would be interesting to hear any progress and if the pandemic has affected the project. <comment><USER2> I wondered the same thing and haven't heard/seen much. I'm working on a UBI story and would like to include YC.</comment>


SimTK: open-access biomedical research models and tools - <AUTHOR> https://simtk.org/xml/index.xml <comment><USER2> SimTK is part of Simbios: [http://simbios.stanford.edu/](http://simbios.stanford.edu/)</comment>


SQL Keys in Depth - <AUTHOR> https://begriffs.com/posts/2018-01-01-sql-keys-in-depth.html <comment><USER2> After a decade of large systems relying on RDBMs, we now use 64-bit integers for all primary keys with a global Hi/Lo id generation system (app reserves a range of numbers on startup to assign to records automatically).

This means plenty of ID space, maintains rough numeric ordering, allows ID creation without a roundtrip for every insert, is easily portable across different databases, and produces unique IDs for every row in the database which greatly simplifies everything from caching to replication.

<comment><USER3> does seem to me that the author is a hobbyist or a junior developer with little real word experience.

Literally the first Colum of almost every SQL table I have written has had a column called id with auto increment.

<comment><USER4> The trouble with "natural keys" is that they're rarely actually unique. The barcode is a typical example. A naive developer might use a barcode as a primary key, but will soon be in for a world of pain when he realizes that products often use the same barcodes for different configurations (packaging etc), which usually need different SKUs. The same product from different origins may have the same barcode, which often matters.

<comment><USER5> And a product might get multiple barcodes.

I was a fan of natural keys but it is just too much trouble. For example you have to url encode everything when a key is used in the url.

But sometimes I still use natural keys for tables with for example ISO standards like country codes.

<comment><USER6> I feel like an ISO country code is more of a surrogate key anyway; it's a mnemonic made-up value specifically designed to be used as key.

<comment><USER7> An ISO country code isn't a surrogate key; it's not db-specific, and it has domain meaning (assuming you are using it for it's intended purpose). It's ususlly, when used, a representation chosen for natural domain information, so if it's a key, it's a natural key.

</comment></comment></comment></comment></comment></comment><comment><USER8> "For instance, a database of hobbyist club members could include uniqueness on the two columns first_name, last_name of members. Duplicates are likely unintentional at this scale, and if necessary the constraint can be dropped. Until an actual conflict happens the key is a reasonable precaution."

Absolutely do not do this.

People have names that are duplicates. A situation where someone is unable to join a club because their name clashes with an existing member is not OK.

Expecting a club administrator to be able to drop a uniqueness key from their database in order to resolve this situation is not a reasonable solution!

<comment><USER9> I agree with you, but I think you did overthink his metaphorical example a little.

I think the point was that for a 40 people club odd are very very poor that two people would have the same name. And even if so a club manager could still differentiate by adding a middle name or a nickname (in a 40 people scenario).

Of course IF your neighborhood club expand and you need to manage a lot of people you'll have to switch to a better technique. His point was that you must fit to you business case. (But hey some people change name when they marry so... problems can happen fast, but that's mutability issue not uniqueness).

Overall very good article but keeping critical mind as you did is needed.

<comment><USER10> I'm not convinced that the odds are "very very poor". Some names (like Robert Smith or Maria Garcia) are quite common. And a hobby club is not a random selection of people, members would typically tend towards a specific geographic area, social class or culture depending on the subject. Some cultures have a very limited pool of names, depending on tradition.

<comment><USER11> Just from looking at a 200 member club I'm part of, I can see at least two name collisions in our current club roster. So absolutely agree with your assessment.

</comment></comment></comment></comment><comment><USER12> At what scale does all this stuff start to actually matter? I have an database with ~100 tables and ~500M rows driving a medium-traffic web app and various back-end systems. We use auto-incrementing integers as primary keys and try not to expose them externally. Indexes are added as necessary to enable specific queries. We don't enforce any other constraints (e.g. not-null or foreign keys) at the database level.

... and it all works and performs just fine? The considerations the author mentions all make some sense to me in theory, but when do they actually matter in practice in a modern system?

<comment><USER13> I disagree that UUIDs are generally preferable over integers. For one, they take up more space (on disk and in memory). And for something like a key, it is likely that there will be multiple copies of that value stored, since it will exist in the table itself, at least one index (possibly more) and foreign keys. More space means fewer records per page on disk, more I/O and more memory usage (potentially leading to more I/O). I would wager that for most users (including this case), the cost of this additional I/O is far greater than some theoretical scalability limitation on generating IDs.

Most database vendors make sequence generation (whether through explicit SEQUENCE objects or auto-incrementing columns) performant by making a few compromises:

* Numbers may not always be sequential (you might get 1, 3, 2 - in that order)

* There may be gaps (you might get 1, 2, 5, 6)

But since these are supposed to be opaque identifiers, neither of these compromises should be a concern for most users. But this means that these sequences can live outside of a transaction (you might grab an ID, rollback, and that ID is gone) and that systems with multiple nodes can be allocated a "block" of numbers from which they can quickly pull new values, without needing to coordinate with a master node.

<comment><USER14> UUIDs are the best choice when developer time is more important than space usage. Also, they can be generated and used by the client when the connection to the db is frequently down (eg: clients store/query data locally in SQLlite and replicate to master).

<comment><USER15> I am not a db expert, which is why I like read these kinds of comment threads. But what about this?

[https://en.wikipedia.org/wiki/Universally_unique_identifier#...](https://en.wikipedia.org/wiki/Universally_unique_identifier#Collisions)

"The random nature of standard version 3, 4, and 5 UUIDs and the ordering of the fields within standard version 1 and 2 UUIDs may create problems with database locality or performance when UUIDs are used as primary keys. For example, in 2002 Jimmy Nilsson reported a significant improvement in performance with Microsoft SQL Server when the version 4 UUIDs being used as keys were modified to include a non-random suffix based on system time. This so-called "COMB" (combined time-GUID) approach made the UUIDs non-standard and significantly more likely to be duplicated, as Nilsson acknowledged, but Nilsson only required uniqueness within the application."

<comment><USER16> This article mentions this question. Database locality is a complex scaling question that may not be a problem depending on how read/write heavy your operations are. On the one hand, randomly distributed UUIDs may be a bad idea on a single SQL server trying to balance a single B-Tree index (and thrashing that index with a lot of incoming data); on the other hand it can be somewhat ideal for partition sharding across multiple servers. As with any trade-offs in database design, your mileage will vary with your application needs and resource availability.

Also, there are other options for time-ordered GUID/UUID alternatives. ULID is the one I've been heavily using in projects lately: [https://github.com/ulid](https://github.com/ulid)

(ULID uses a timestamp prefix and random suffix for reasonable time-ordered database locality; an interesting compromise between V1 and V4 UUIDs, though not directly compatible with either. The L stands for "lexicographic" in that its also meant to be sortable in string indices as well, which can be important for database locality in many document/NoSQL databases.)

</comment></comment></comment></comment></comment><comment><USER17> The most important property of surrogates, which I never see mentioned, is that two tuples, _anywhere in the database_ , have the same surrogate key _if and only if_ they are (believed) to refer to the same real-world entity. This is a crucial difference wrt auto-incrementing or randomly generated values that are independent in different relations (which is a common practice). Among the rest, with surrogates defined as above you may freely join relations on surrogate keys being sure that you are joining related data.

In his landmark 1979's paper, Codd defined surrogates and pretty clearly, and that part of his work was based on an earlier paper entitled On Entities and Relations (I don't recall the authors right now), so this is not exactly news.

Unfortunately, current DBMSs provide little to no support for properly implemented surrogates.

<comment><USER7> > Unfortunately, current DBMSs provide little to no support for properly > implemented surrogates.

UUIDs instead of per-table autoincrement keys seem to be a solution which covers the part of the problem that involves DB support as opposed to data model design, and several DBs have adequate support for UUIDs.

<comment><USER18> UUIDs (and other mostly random IDs) also have the important advantage that they can be generated offline - in mobile apps, client-side javascript or elsewhere.

With autoincrement keys, you need to either contact the database server for each data object you create, or implement complex logic to replace temporary IDs with database IDs later.

<comment><USER19> Nope, you can't. You still have to check for uniqueness on the server side before committing them, so you are back from the start.

Always keep in mind that anything coming from the client cannot be trusted.

<comment><USER18> You can't blindly overwrite existing data based on the UUID, sure.

But I find that the security checks against "stealing UUIDs" are much simpler to implement than a system of composite primary keys (deviceid+autoincrement or userid+autoincrement) or some sort of temporary primary keys. If you see suspicious UUIDs, you can just discard the data.

Having the client generate the "final" IDs for objects is particularly convenient when the client can produce a complex graph of objects offline, for example an order + order items + comments + more. If using temporary IDs until first contact with server, all these links would have to be patched up when the objects get real server-side-assigned IDs.

</comment></comment></comment></comment></comment><comment><AUTHOR> A review article that combines original research, excellent writing, and useful advice. Impressive!

<comment><USER20> Yeah, not the usual poorly argued heresay. Good job author.

</comment></comment><comment><USER21> On Postgres I prefer to use a single sequence to generate ids across all tables. This reduces the chance of accidents (eg accidentally deleting the wrong thing with id #123) and reduces information leakage ("oh, I see I'm customer #5, you must only have 4 other customers").

<comment><USER22> That's not a bad option, but I think I'd find locally-unique integer IDs spread across tables to be a little confusing. In that case I think I'd lean towards UUIDs, which may be a little easier overall, or use separate sequences but expose IDs via Hashids in my API/frontend: [http://hashids.org](http://hashids.org)

<comment><USER23> In Postgres, having multiple tables share a single ID sequence is trivial thanks to SEQUENCE/NEXTVAL.

<comment><USER16> Sure, but Postgres doesn't to my knowledge support a cross-table UNIQUE index to insure your sequences are followed in all cases. I imagine that all it takes is one confused junior developer to add a bunch of manually IDed data by hand to create some weird and confusing corner cases in this scheme.

<comment><USER23> You can define the field as GENERATED ALWAYS, though, in which case specifying the value explicitly in INSERT won't work (there's an escape hatch, but it has to be explicitly and very verbosely invoked).

</comment></comment></comment></comment></comment><comment><USER24> It's an interesting article with interesting ideas.

I'm squarely in the camp of using natural PKs until there is good reason to use surrogate PKs.

I generally disagree with the notion of using a combination of surrogate and natural keys. In SQL, a PK isn't just another unique key: a PK an important block of communication.

As a rule of thumb, when a PK is attached to a semantic value, it is saying that this is the identifier of the table. If a PK is on a surrogate key, it is saying that there is no good unique identifying value in the table. When you are dealing with larger data sets, this distinction isn't minor, as it helps to understand the intent of the data when working with it. PKs serve as guideposts in your design along with guideposts to the person who has to maintain (or fix) your database later on.

I know some disagree with me on that, but there are many undeniably good reasons to use a natural key. A good place is a check-constraint table, where you say, have a list of US states and you want to ensure that "New York" and not "New Yoerk" inserted into the state column of an address table. Put a PK on valid_state_names and FK to the PK from addresses.

<comment><USER6> > If a PK is on a surrogate key, it is saying that there is no good unique > identifying value in the table.

Almost always there is no good unique _unchanging_ identifying value on a table. Take something as simple as "Person" \-- there is literally no unique unchangeable value for such an entity. And that's the rule more than the exception.

I take exactly the the opposite approach; nearly all entities should be identified with a surrogate key. You pretty much cannot go wrong with this approach.

In the US state names are pretty stable, but in other countries state/province names have changed so even that value is poor choice for a primary key.

<comment><USER24> Yes, each set of data should reflect the data you want to use. That's why I said I default to natural keys unless there is good reason to use a surrogate key.

If I have to compare databases I've worked on over the years, the databases that are all surrogate will have many more data errors than a database that is predominantly natural keys. I could write a book on why that happens, but if you don't know relational theory cold (not saying you don't), you should just use natural keys. The short answer is that using all surrogate keys is equivalent to not using unique constraints at all.

Data is bound to change at some point in the future. The entire point of having constraints is to ensure that your data keeps its integrity, now and later on, no matter how the data needs to be updated.

<comment><USER6> I'm working with a 3rd party database right that used more than a few natural keys and it's awful. The primary key for "users" is username so we can't rename our users to improve our company's username security policy. And that's just _one_ of the problems. We'll be offline for a full 24 hours in April to handle changing the value (for necessary business reasons) of the natural primary key in the client table.

I'm all for constraints, especially uniqueness constraints, where appropriate. You can use unique indexes; you don't have to use natural keys as primary keys. Data is bound to change, so make that change possible.

<comment><USER24> A badly built database isn't the reason to toss out good practices.

It's actually quite obnoxious to see how bad many databases are, and this often causes a blow-back of tossing the baby out with the bathwater. It's a trap.

I'm not really sure what all the problems are, but if changing username to something else is causing a 24 shutdown, there are many deeper issues than a PK on username.

<comment><USER6> > A badly built database isn't the reason to toss out good practices.

It's a good reason to toss out bad practices like, for example, using natural keys as primary keys. Which is, almost universally, considered a bad practice. It is, in fact, the bad practice that causes the most pain in this bad database.

> if changing username to something else is causing a 24 shutdown, there are > many deeper issues than a PK on username.

This is true; the software is so old it pre-dates most modern RDBMS features and that is a factor in the database design. And it contains a few decades worth of data. And the process to go through the _all_ records and re-do every foreign and primary key value is expensive (through the app server) but is a well-tested path. None of this would be necessary, however, if they had used surrogate keys for these tables. They did use surrogate keys for other tables so it wasn't a technical limitation.

<comment><USER25> I'm curious what database this is. Even mysql supports ON UPDATE CASCADE back to 5.5 (or earlier?).

</comment></comment></comment></comment></comment></comment></comment><comment><USER26> The very first example implies its own counterexample. In most decks of cards there are 2 jokers.

<comment><USER27> One red, one black.

</comment></comment><comment> B-Con > One thing to avoid in publicly exposed numbers is sequential order. It > allows people to probe for resources (/videos/1.mpeg, /videos/2.mpeg etc) > and also leaks cardinality information. Add a Feistel cipher on top of a > sequence. This hides the ordering while maintaining uniqueness.

> The PostgreSQL pseudo encrypt wiki gives an example cipher function: > [...]

I get that they want to leave the key value in the schema, but practically this kind of thing feels worth pulling out into the storage engine. Just generate a random string as the ID upon row insertion and force uniqueness on that column. If insertion fails, generate another random string. (And it should pretty much never fail because otherwise you're still suspect to the enumeration attack you're trying to prevent.)

Although given that Postgres can read from a file, could the above be done in the schema by reading from /dev/urandom? If so that seems like the better approach.

</comment><comment><USER28> >Modern SQL is supposed to abstract from the physical representation. Tables model relations, and should not expose an implicit order in their rows. However even today SQL Server creates a clustered index by default for primary keys, physically ordering rows in the old tradition.

Which is why the UUID (or GUID in SQL Server speak) can have other drawbacks there in comparison to auto incrementing bigints, namely delays due to the data being ordered randomly on disk. There are obviously ways to counter that like adding extra non-clustered indexes or changing the clustered index to something besides the primary key, but at that point the extra time and overhead might defeat the benefits you gained from going with UUIDs in the first place.

<comment><USER29> Isn't that exactly what the NEWSEQUENTIALID function was created for?

[https://docs.microsoft.com/en- us/sql/t-sql/functions/newsequ...](https://docs.microsoft.com/en- us/sql/t-sql/functions/newsequentialid-transact-sql)

<comment><USER28> In theory yes, it solves some of the problems and introduces others. It isn't usable everywhere NEWID is usable, so if you assign UUIDS as part of a query you are out of luck. It also assumes you are generating all your UUIDs on the same machine without restarting which once again negates some of the benefits of UUIDs.

<comment><USER30> ULIDs solve these issues.

Basically 48 bits of millisecond timestamp then 80 bits of randomness.

The technique has been used in MSSQL apps since about 2003 (although people called them COMBs instead of ULIDs back then)

[https://github.com/oklog/ulid](https://github.com/oklog/ulid)

<comment><USER28> Nice, I hadn't seen that before. It looks pretty good on first glance.

</comment></comment></comment></comment></comment><comment><USER20> This is well done. And yet many people get this stuff wrong. As a language person, I think about how we could make these choices more natural by rewriting SQL; make them the path of least resistance rather than requiring much pondering and wisdom.

<comment><USER31> Let's be honest: If _you_ could make these choices more natural then you would have done so by now. If you could make SQL better than it is, you already would have done that as well. In fact, if most people who are interested in SQL could make SQL better than SQL is, we wouldn't be using SQL anymore.

We're not using it because we have some weird tradition we enforce. We're not using it because we like the way it looks, the way it writes, or the way it handles. We're not using it because we've tried to use ORMs and those ORMs have proved conclusively better across use cases than SQL.

The reason we use it is because we don't yet have a better solution. If you can write a better solution than SQL I would love to hear about it: I absolutely loathe SQL, but I use it because out of everything I've seen, it's the simplest and most elegant solution to the problem that I've ever come across.

So yeah, while we could possibly and should definitely make SQL better if we can, I don't think that suggesting that we just re-do it from scratch is the way to go. That way lies madness, and possibly javascript frameworks.

<comment><USER32> I think you're discounting network-effects and historical inertia.

Even things which are functionally very simple to implement won't necessarily catch on, ex: "If _you_ could make keyboard layouts more practical than QWERTY, then you would have done so by now."

<comment><USER31> I mean, maybe I am, maybe I'm not. How many other languages from the '70s haven't been replaced in a domain where they should have been?

And, I mean, maybe your example isn't really the best example you could have given. Name a layout quote-unquote more practical than QWERTY that should have caught on but didn't. Dvorak? No faster. Colmac? Nah. Any, y'know, studied benefits? None I can find, at least not with a P-value worth mentioning.

I'm not saying SQL is the definitive end of database query languages, of course, because that would be silly. There is, almost certainly, a more objective truth. What I'm saying is good luck finding it; It's only semi- cynically that I say I wish you luck finding a better language than SQL. I honestly, with all my heart, wish that SQL could be replaced with something better, because I hate SQL.

When some guy comes along and is like "we should do a better SQL!" the answer is yes, we should, but I'm not exactly going to hold my breath,

<comment><USER33> > And, I mean, maybe your example isn't really the best example you could have > given. Name a layout quote-unquote more practical than QWERTY that should > have caught on but didn't. Dvorak? No faster. Colmac? Nah. Any, y'know, > studied benefits? None I can find, at least not with a P-value worth > mentioning.

Do you believe that all keyboard layouts are of indistinguishable practicality? That seems to be the inescapable conclusion of your claim.

<comment><USER34> > Do you believe that all keyboard layouts are of indistinguishable > practicality?

If you have evidence to the otherwise, a lot of us would be keen to read it.

<comment><USER33> I'm happy to take hug's claim that there _is_ no such evidence at face value. What I'm really interested in, however, is whether the absence of such evidence causes him/her to believe that _there is no difference_.

</comment></comment></comment></comment></comment></comment></comment><comment><USER35> One thing to keep in mind with Postgres is that unique key indices can lead to deadlock and stall other transactions that insert the same key.[1]

I wouldn't say "unique constraints considered harmful" but I would definitely say they can be surprising and must be used with care.

[1]: [https://rcoh.me/posts/postgres-unique-constraints- deadlock/](https://rcoh.me/posts/postgres-unique-constraints-deadlock/)

<comment><USER36> The relatively new "INSERT ... ON CONFLICT" mechanism is a great way to circumvent this issue. Using that feature, you can tell it to ignore conflicting dupes, or you can have it transform the insert into an update.

</comment></comment><comment><USER37> "There's no need to manually create indexes on columns already declared unique; doing so would just duplicate the automatically-created index." Is the last part real? Makes me feel like forking postgesql just to save the world from accidental duplicate expensive indexes.

<comment><USER38> Yes, in PG at least an index is created, otherwise the unique check would become prohibitive.

<comment><USER39> I think the question is more on whether a duplicate index would be created instead of having the unique constraint and primary key designation on the same column share an index

</comment></comment></comment><comment><USER40> Funny example in regards of a card-deck. How would you have unique keys for the 3 jokers in the deck ?

<comment><USER41> A joker does not have a suit, nor a number, so it would not fit in the example table anyway.

<comment><USER16> Arguably Joker is the number, and like Ace is 1 you might use 0 or 14 depending on math preferences as a surrogate number (or stick to the character designations like A, K, Q, J).

Decks with four jokers typically have suited jokers. Decks with two are typically (though not always) red/black and could be given arbitrary suits (say hearts/spades).

</comment></comment></comment><comment><USER42> programmers who are intrigued by the recommended pg_hashids extension have a wide variety of alternatives to using a pg extension for the same key obfuscation logic: [http://hashids.org/](http://hashids.org/)

</comment><comment><USER43> Great article.

But MAC address cannot be considered unique, as soon as software like keepalived is running.

<comment><USER44> OK. But how does that relate to this article? If you're using keepalived what you're doing is moving the connection from one instance to another if the current one is detected as being dead. Even if only the MAC was used to generate the UUID (which it is not, timestamp is factored in too) I struggle to find a scenario in which this would be a problem. Even if you time it down to the nanosecond, if keepalived is used as intended you'd never generate a UUID at the same time on a number of machines sharing the MAC.

And from a privacy concern, if the MAC cannot be considered unique, that's only a bonus?

<comment><USER43> The article list the MAC address as a _natural unique key_

        Here are some values that often work as natural keys:

        [...]
        mac address on a network
        [...]

that was the reason for my comment.

<comment><USER44> Ah, I missed that this was what you were commenting on. I thought it was about the use of the MAC in the UUID generation.

Thanks!

</comment></comment></comment></comment><comment><USER45> hey, is it me being far from expert, or:

why use UUIDv1 if you can just use timestamp?

wouldn't time-based solution be prone to time misconfig across servers? Or that little shuffle doesn't really matter?

</comment><comment><USER46> The reading was worth because of the curse generator anedocte.

</comment><comment><USER47> There are two things this article could point out:

The difference between centralized, distributed and decentralized primary keys.

And how public/private key encryption should be a natural part of every primary key.

The problem is all SQL databases uses sync clients which make them completely useless in any distributed or decentralized setting.

The real tension here is that there is no guarantee that a large UUIDs are unique, and we have not embraced the random occurrence of a collision.</comment>


TCP Silly Window Syndrome - <AUTHOR> http://www.tcpipguide.com/free/t_TCPSillyWindowSyndromeandChangesTotheSlidingWindow.htm

<comment><USER2> Silly window syndrome was fixed in TCP around 1983. Unless someone really botches a TCP implementation, it should not be a problem today.

The article has a section "Sender SWS Avoidance and Nagle's Algorithm" and claims that they're related. They're not, except that in some sense they're duals. Silly window syndrome occurs when the pipe is almost full and the reading end is making tiny reads. The tinygram problem, which is addressed by Nagle's Algorithm, occurs when the pipe is almost empty and the writing end is making tiny writes. Silly window syndrome is easy to fix, because doing tiny reads from a full pipe doesn't mean the sender has to be informed immediately that there's space for a tiny bit of new data. The receiver doesn't send a window update until there's some serious space available. But tiny writes on an empty pipe come up often in practice, and senders want their tiny data items delivered promptly, so tinygram prevention can't be as heavy-handed.

(A long time ago, when TCP was being designed, I used to have to worry about this stuff. John Nagle)

<comment><USER3> Well spotted. But why is this article still on the front page 4+ hours later? Are people disagreeing, ignoring the comments, or appreciating this for historical reasons?

</comment></comment><comment><USER4> Why is this behavior "silly"? It seems to me like it's the correct behavior under the described conditions. (I'm not a networking expert though.)

If the server is incapable of handling the amount of data that the client is sending, shouldn't the buffers get smaller and smaller until they reach a size the server can handle reliably? (Assuming other variables like the latency of the connection or server load aren't changing.) If the server really can only handle a byte of data in the time it takes for a round-trip message, then it seems correct for the client to only send it one byte at a time...?

<comment><USER4> (Oh I just realized that there are more pages to the article - the "next article" button caused me to overlook the "next page" button. Perhaps they explain what the problem is on subsequent pages.)</comment></comment>


India state approves life term for killing cows - happy-go-lucky http://www.bbc.com/news/world-asia-india-39454607 <comment><AUTHOR> But that most exclude Muslims and Christians, right?</comment>


Anonymity and the Dark Side of the Internet - <AUTHOR> http://opinionator.blogs.nytimes.com/2011/01/03/anonymity-and-the-dark-side-of-the-internet/

<comment><USER2> Anonymity is vitally important. The claim is that sunshine is a good disinfectant, and that's generally true, but when it comes to communication, sunshine (the scrutiny of others) can have the opposite effect, it can infect your speech with false ideas. Our time is as bad as any other when it comes to heresy.

There are groups out there who will persecute you for saying the truth. If you don't believe this, try taking a public stand against the actions of a certain new religion. Or try making any criticism at all of a certain old religion. These groups and others like them have made it extraordinarily costly for an individual to associate themselves with perfectly correct beliefs. And now the same groups would like to strip others of their anonymity, ostensibly so they can stamp out any dissent at all.

As someone who values the truth, I find this troubling.

</comment><comment><USER3> 'What is remarkable about this volume is that the legal academics who make the arguments I have rehearsed are by and large strong free-speech advocates. Yet faced with the problems posed by the Internet, they start talking about "low value" speech (a concept strong first-amendment doctrine rejects) and saying things like "autonomy resides not in free choice per se but in choosing wisely" and "society needs not an absence of 'chill,' but an optimal level."(In short, let's figure out which forms of speech we should discourage.)'

Depressing.

<comment><USER4> What part of this depresses you?

<comment><USER3> That people I respect who used to be free speech advocates now are talking about "low value" speech etc. Check out the quote from Daniel Solove: "the law is hampered because it overprotects free speech."

<comment><USER4> Do you really think there's no such thing as "low-value speech"? I'm not asking whether you think it's OK to regulate it.

<comment><USER3> Different levels of speech get different protection (political speech, commercial speech, etc.) but I don't like the term "low-value speech". Who decides the value?

<comment><USER4> What about categorically low-value speech? Deliberately false and malicious speech?

<comment><USER3> Defamatory speech isn't protected. But I still don't think "low-value" is a helpful description.

For example take comments on Slashdot or wherever saying "first post" (or "first comment" or whatever). Do they have value? Most would say no. Does that mean they shouldn't be protected?

<comment><USER5> Defamatory speech is also protected to a degree because it isn't possible to weed out beforehand, but carries consequences and could be censored after the fact.

<comment><USER3> I meant "protected" in the legal sense, but you're right.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> I haven't given this too much thought but it strikes me that it is the medium rather than the message or messenger that is troubling. It just might be difficult for people to understand the internet.

Think about it this way- we have no idea if someone is writing an opinion piece in the newspaper under a pseudonym. Sure, we could take it up with the newpaper legally, but that doesn't really change anything, and that might be the only difference between a newspaper and google in this case; google couldn't find out exactly who it was, but a newspaper should know.

Or, someone in academia could be completely faking credentials, name, tenure, experience and without diligence we wouldn't be aware. Again, it is more verifiable than someone leaving anonymous responses on Yelp or Google, but is that the main difference then? if we can reference check that person?

Another, maybe more naive way for me to think about this is that when I manage a team I don't make rules to stop the edge case/corner case behavior...you give guidelines and a high level overview of what acceptable behavior is. Otherwise you end up with a really strict, really rigid environment with rules that no one can comprehend or follow for some reason that no one can remember. No one wants to live in that environment. If we enact legislature to stop extremely low percentage behavior we end up in a similar spot politically. Not sure it is a solid argument, but it seems to make sense, roughly.

</comment><comment><USER7> I believe the author is taking issue with the notion that "the truth will out" in the marketplace of ideas.

In this I sympathize with Fish. It is as though the truth's-being-out was some final result, rather than merely an ephemeral change in constantly changing cultural winds. This smacks of the happily-ever-after narrative to which America so frequently retreats, having not as a culture experienced any evidence to the contrary since the Civil War (perhaps none ever, since even then, righteousness prevailed, no?).

Even if the inconvenient truth is for a period (we cannot say "finally") adopted as the social consensus, what of the damage done in the meantime?

</comment><comment><USER8> More barely concealed anti-wikileaks pro-facebook propaganda from the establishment.</comment>


Ross Ulbricht's private journal shows Silk Road's birth - <AUTHOR> http://arstechnica.com/tech-policy/2015/01/silk-road-trial-fbi-reveals-whats-on-ross-ulbrichts-computer-in-open-court/ <comment><USER2> >"On that day, a male and female agent started an argument in San Francisco's Glen Park public library, to get Ulbricht's attention. As soon as Ulbricht was distracted, another agent grabbed the open computer"

And that, ladies and gentlemen, is how you defeat crypto. How could you even defend yourself against such a thing? The only thing that comes to mind is never working in public on a computer.

<comment><USER3> Someone should invent a usb dongle that detects a nearby rfid chip that you keep on your keychain. As soon as that keychain is out of range, say 5 feet, the computer locks and encrypts itself. Integrate this into the computer and you wouldn't be able to tell who has one and who doesn't. Think you're being arrested with your computer open? Toss your keys.

<comment><USER4> _Toss your keys._

But then the LEO agent sees this, and not only does he pick up the keys, he will then proceed to charge you with something for resisting arrest, or obstruction of justice or any of the myriad of ways they have to make your life a living hell.

I think this would be similar to smoking pot in a moving car, then getting a police car to tell you to stop and then you throw the drugs out the window. I believe that's enough of a reason to charge you with all sorts of nasty stuff.

<comment><USER5> Yeah but when you "throw the drugs out the window" they don't disappear.

<comment><USER4> That's my point. If you have your laptop locked depending on whether they are close by or not, then throwing the key away will not help you.

I was trying to say that it seems to me as an ineffective method. Just as ineffective as trying to argue with the police that since you don't have the drugs on you (because you just tossed them) you are not in trouble. The drugs don't disappear just as the keys won't, so the agents would just have to get the keys and unlock your laptop.

</comment></comment></comment></comment></comment><comment><USER6> I think "Do things that don't scale" applies perfectly here, the part where Ross initially seeds the marketplace by selling magic mushrooms which he himself grew; may be this explain why new Darknet concepts failed to take off, not due to technological limitation or lack of market need.

[https://bitcoinmagazine.com/5285/torbroker-anonymous- finance...](https://bitcoinmagazine.com/5285/torbroker-anonymous-finance-and- trust/)

[http://www.forbes.com/sites/andygreenberg/2013/11/18/meet- th...](http://www.forbes.com/sites/andygreenberg/2013/11/18/meet-the- assassination-market-creator-whos-crowdfunding-murder-with-bitcoins/)

<comment><USER7> I just want to grab this kid and shake him while screaming "WHY WOULD YOU EVER WRITE THAT SHIT DOWN?!?"

It's like he _wanted_ to get caught...

<comment><USER8> _In a folder labeled "TorChat," Ulbricht's computer holds years' worth of chat logs._

Felt the same way when reading this. Seriously - three years worth of chat logs? I don't think he wanted to get caught, he just felt that a clueless investigator could never decrypt his data, a clueless prosecutor could never understand let alone describe his operation and a clueless jury would never understand it.

So far we know he underestimated the investigator and the prosecutor. We'll know soon if he misjudged his chances with a jury.

<comment><USER9> Never assume you're the lone wolf in a world full of sheep....

</comment></comment></comment></comment><comment><USER10> These are very intimate details of his life. The entries do not read like the entries of a psychopath, rather they paint a vivid picture of his life and the perfect basis for a movie.

<comment><USER11> I've never gotten the impression that Ulbricht was a psychopath or anything similar. He always came across as a naive idealist, caught way over their head in a conspiracy they never expected to succeed. He openly admits in his diary that he practiced terrible OpSec, and didn't care much.

<comment><USER12> This article doesn't make him look like an idealist at all. It makes him look like an entrepreneur that cares about success about all else. The idealism seemed to come later, as a justification.

<comment><USER13> Being an idealist and entrepreneur who wants to be successful are not mutually exclusive at all.

<comment><USER12> Who said it was?

</comment></comment></comment></comment></comment><comment><USER14> It all seems more amateurish with every additional piece of news coverage - why a single decryption key or even your day-to-day laptop as storage for that multitude of evidence! Surely you don't need 4 years of chat logs to run a site on a day to day basis.

</comment><comment><USER15> The snatching of the computer before you have a chance to lock it issue seems like something that could be solved with software. I'm imagining a "swatd" service that listens for loud noises (gunfire, flashbangs, shouting, etc) or observes the camera for sudden motion and locks the machine. I'm sure there'd be some false positives from movies and the like, but for guys like this, better safe than sorry.

<comment><USER16> If the target manages to lock the computer, the next thing to do is to freeze the RAM sticks and try to get the encryption key from there: [http://citpsite.s3-website-us- east-1.amazonaws.com/oldsite-h...](http://citpsite.s3-website-us- east-1.amazonaws.com/oldsite-htdocs/pub/coldboot.pdf)

"We also confirmed that decay rates vary dramatically with temperature. We obtained surface temperatures of approximately −50C with a simple cooling technique: discharging inverted cans of "canned air" duster spray directly onto the chips. At these temperatures, we typically found that fewer than 1% of bits decayed even after 10 minutes without power. To test the limits of this effect, we submerged DRAM modules in liquid nitrogen (ca. −196C) and saw decay of only 0.17% after 60 minutes out of the computer."

<comment><USER17> Ulbricht's Samsung 700Z laptop used DDR3 RAM. These guys couldn't reproduce the "cold boot"/"RAM freeze" attack using DDR3 RAM: [http://www1.cs.fau.de/filepool/projects/coldboot/fares_coldb...](http://www1.cs.fau.de/filepool/projects/coldboot/fares_coldboot.pdf)

But I don't see why they would need to freeze anything. I would think the feds should be able to make a device that plugs onto the DRAM connectors of chips and reads the content, although I'm not sure.

</comment></comment></comment><comment><USER18> Those journal entries don't really read like journal entries to me. The longer entries seem more like prepared and considered stories--stuff written for an audience other than yourself. I wonder if he was keeping those as notes for a book.

<comment><USER19> A book he could never publish. Unless he got caught.

<comment> k-mcgrady Write it and have it published when you die I suppose is the other solution.

<comment><USER20> Or after the statute of limitations runs out, but I'm not sure how long that would be for the crimes he's accused of.

</comment></comment></comment></comment><comment><USER21> Reading this, and other recent events, gives me the realisation that we need the successor of UNIX. Nowadays, everything runs UNIX. My iPhone, Android, my Mac, my Ubuntu laptop, my Debian or BSD server, even my e-reader runs some Linux.

On recent systems like iOS & Android applications run pretty isolated. You can't read and write the whole file system (afaik), and you need to have the user tap "yes" to use many system API's (like microphone, camera, etc).

Using UNIX for a desktop computer, you don't really utilise the user system. Everything I run is either as my own user, or as root (when adding/remove packages or doing system updates). Otherwise, it's a singe user system. So any program I run can read all permanent data stored by other programs in my home directory. In effect, all programs have 100% access (except for changing system settings, but why would they care when there is only one user to own?

When I encrypt my drive, I encrypt it all but also unlock it all when logging in. It's inherent to the system that my whole home dir is open when using (except for things I encrypt manually, like GPG mail or other user land things). Defaults matter. That's why Ross's documents were readable to the American government.

I think we need a new OS to take over after UNIX. One that is built up of sandboxed modules. Where each program gets it's own file system, where they can do whatever they want. That file system is, if I wish, encrypted until I chose to open it. It could be encrypted with a public key system, so I can have many FS's opened with one key, or derive keys from a master key.

These small systems could even be virtual machines, I can't say anything about the eventual overhead that would bring.

In short, UNIX is bad because the file system is bound to my user, and anything my user runs has 100% access to everything else I run. The user system is nice, but not practical. If it was, Ross would be a free man.

<comment><USER22> In theory LXC could do this. It needs to be tested more and clearly has security issues right now.

</comment></comment><comment><USER23> In his diary regarding selling out of (illegal) mushrooms he writes: "...but at least now I was all digital, no physical risk anymore."

Given the revelations from the last few years, how many of you would agree that carrying out an illegal plan like this is safer online?

</comment><comment><USER24> I never saw the number, what was DPR net worth when this all came to a crashing halt? I assume 10's of millions of dollars

Also - was that money recovered by the FBI or could they not find his private keys?

<comment><USER25> I think the peak number in the spreadsheet for the value of SR was $104M -- I can't remember the source, but that figure stood out.

edit for source: [http://abcnews.go.com/Technology/wireStory/san-francisco- man...](http://abcnews.go.com/Technology/wireStory/san-francisco-man-faces-ny- trial-tuesday-silk-28149351)

The FBI had no problem finding his keys because he kept them in a folder called, "Keys" \-- the kid was not an OpSec genius..

[http://motherboard.vice.com/read/journal-and-chat-logs- from-...](http://motherboard.vice.com/read/journal-and-chat-logs-from-ross- ulbrichts-laptop)

</comment></comment><comment><USER26> I feel like this applies here: [https://www.youtube.com/watch?v=hGo5bxWy21g#t=1m19s](https://www.youtube.com/watch?v=hGo5bxWy21g#t=1m19s)

</comment><comment><USER27> It sounds like a scene from that terrible TV show "What Would You Do?" I'd ignore it that's what I would do.

</comment><comment><USER28> This "diary" sounds like it was written by the FBI and planted on his computer...

<comment><USER9> It's surprising how much effort some on HN will go through to insist the case against Ulbricht must be completely invalid somehow. Several people in this thread have already assumed that because the FBI has his laptop, that must mean they stole it without a warrant. And now, if they found his diary, well, they must have planted it.

You may have to come to terms with the possibility that the FBI actually has a case supported by evidence obtained through legal means.

<comment><USER29> DPR definitely broke the law, there's no question about that. A lot of us think it's an unjust law, but whatever. He may have also put out hits on people (though, curiously, he is not being charged for that). If that's the case then he's also a danger to society and really does belong in prison.

But, it is immensely frustrating, even heartbreaking when you consider the cost in human lives, that given the choice between something like Silk Road and Mexican drug cartels, we as a society have apparently chosen Mexican drug cartels, and all the gut-wrenching bloodshed and destabilization they bring.

I'm reserving judgement on Ulbricht the person, but what he did should not be illegal, for reasons ideological, practical, and humanitarian.

<comment><USER9> I'm not entirely certain that black markets are the best way to facilitate a safe drug trade, but given a choice between Silk Road and more violent alternatives, Silk Road seems like the obvious better choice.

<comment><USER29> Right. Aside from, or in spite of, being a black market (by necessity), Silk Road was pretty benign compared to the alternatives. Surely Silk Road was taking some profits away from drug cartels. Probably not much, but a legal market would put them out of business. Now with Silk Road gone, all that trade is back under the umbrella of the cartels again, and the profits are theirs.

</comment></comment></comment></comment></comment><comment><USER30> I'm ignorant of the law here: This article starts off saying basically that the FBI agents distracted him long enough to steal his computer and image the hard drive...is that legal? I thought you needed a warrant or something for situations like this?

Or is it illegal-but-it's-ok-it's-the-FBI-shhhh?

<comment><USER31> They already had a warrant for his arrest, as well as for the computer. They just didn't want him to be able to turn off the computer, encrypt itself, and have it become inaccessible to them.

<comment><USER32> Imagine if you were the agent who grabbed the laptop, and you accidentally bumped the power button. Or if you were the forensic tech, and you accidentally triggered a reboot of some sort. No pressure!</comment></comment></comment>


Is this the blockchain moment? Blockchain as software for smart city - <AUTHOR> https://www.youtube.com/watch?v=07zBCiILvyc <comment><AUTHOR> Disclosure: I am creator of this network.</comment>


Black box optimization competition for academia and industrial solvers - <AUTHOR> http://bbcomp.ini.rub.de/index.html <comment><AUTHOR> The results from 2015: [http://bbcomp.ini.rub.de/results/BBComp2015GECCO/summary.htm...](http://bbcomp.ini.rub.de/results/BBComp2015GECCO/summary.html) [http://bbcomp.ini.rub.de/results/BBComp2015CEC/summary.html](http://bbcomp.ini.rub.de/results/BBComp2015CEC/summary.html)</comment>


German Out-of-Home ads can now track your position (German) - <AUTHOR> https://www.horizont.net/tech/nachrichten/ooh-planner-walldecaux-will-out-of-home-mit-neuem-tool-addressable-machen-177444 <comment><AUTHOR> Leading OOH company WallDecaux and mobile tracking company Adsquare have just announced the creation of a platform called "OOH-Planner", to track people watching OOH ads through their mobile phone.

The announcement: [https://youtu.be/hoxPJRoNp34](https://youtu.be/hoxPJRoNp34)

</comment><comment><USER2> Their website at [https://www.walldecaux.de/mobile-ooh#multimediale- kommunikat...](https://www.walldecaux.de/mobile-ooh#multimediale- kommunikation) only lists QR codes, iBeacon and NFC, while the article says (translation):

> This is only possible because Adsquare's "OOH-Planner" evaluates data from > 43 million smartphones in realtime in the background.

Okay, the tech behind this can almost be called trivial at this point, just like data integration with whatever their existing database was, but how in the hell is that not illegal, especially if they combine data into profiles? Even if they hide it in some pseudo opt-ini legalese, I remember a lively debate here in Germany around the time tracking garbage cans were deployed in London, and that was before GDPR was introduced.

Edit: Removed rant about developers at these companies, because the tech seems to be different than proximity based sniffing. According to PDFs [0] on their website they use app data from a plethora of platforms and get anonymized phone traffic data from a company called MotionLogic, which in turn seems to get their data from Deutsche Telekom [https://www.t-systems.com/de/en/solutions/digitization/solut...](https://www.t-systems.com/de/en/solutions/digitization/solutions/outdoor- analytics/traffic-analysis-75652) \- good job privatization, the then government based entity now sells your movement data to ad companies.

I really wonder how "anonymized" all their data really is after integrating all of their sources. Feels like an almost laughable claim.

[0] [https://www.walldecaux.de/smartnet#download](https://www.walldecaux.de/smartnet#download)

<comment><AUTHOR> Right, and looking at Adsquare partners, you find apps such as wetter.com or The Weather Channel.

So weather apps just track the real time position of their users and resell it to adsquare? I'm really dumbfounded, but this appears to be true: [https://www.technologyreview.com/f/612719/the-weather- channe...](https://www.technologyreview.com/f/612719/the-weather-channel-app- has-been-accused-of-tracking-users-and-then-selling/)

<comment><USER2> Not that point 10, their list of tracking stuff, wasn't long enough to worry about already but I fail to find real time geo data mentioned in here: [https://www.wetter.com/datenschutz/adsb/](https://www.wetter.com/datenschutz/adsb/) Might be that one of those third parties infers it via Geo-IP (let's hope so).

<comment><AUTHOR> Right, it seems they only use tracking to display ads for their app/website.

But then I wonder why they would be listed as Adsquare partner for their proximity targeting technology? Geo-IP can be used in some cases (weather, events), but is in other cases not precise enough for real proximity targeting.

Also, strangely, all Adsquare listed proximity targeting partners are apps or companies that have direct access to their users GPS position.</comment></comment></comment></comment>


Blank HTML Document - <AUTHOR> https://www.wired.com/2010/02/blank_html_document/ <comment><USER2> I dont get this.

<comment><AUTHOR> It's just a fun relic of an older internet. Seems like something unlikely to be found on a big website like Wired.</comment></comment>


Ex Apple TV Engineer: New Apple TV UI is actually one Jobs threw away years ago - <AUTHOR> http://9to5mac.com/2012/03/24/former-apple-tv-engineer-new-apple-tv-design-is-actually-one-steve-jobs-threw-away-five-years-ago/ <comment><USER2> A few of the other engineers I work with think I'm crazy, but I'd bet $100 that in the next few years, Apple will produce a TV itself and remove this product from the market.

The well-known comment in the Jobs biography tipped their hand about a further commitment to TV. Literally everybody I've talked to about it balks at the idea of a full-on Apple tv set. That it's too murky, too much tangling with cable providers. Too much competition with existing set makers without the ability to really revolutionize the form-factor like cell phones. That instead they'd just give you a box that you can plug into an existing TV to make it good.

But Jobs (and Apple) have always been about "the whole widget." Moreover, they have a lot of experience building really great large displays.

Besides, TVs need it now. So-called "Smart" IP tv's are the future. TV's already have Apps. And the experience sucks because Samsung, LG, Sony, etc, are not in the business of making first-class software products. I believe the line where steve said he'd "finally cracked it." Because a lot of us I'm sure can see the rough outline of a product there. Let it run iOS. Let me remote control it with my other iOS devices. Let me integrate iTunes/etc in a first- class way. The murky part is: How exactly do you deal with existing cable content. Can I add HBO West to my home screen like an "app" right alongside the HBO Go app? That integration of these 2 side-by-side systems of content delivery (Cable and Internet) is the detail that I think needs to be "cracked." How great would it be to see this product emerge as posthumous part of Jobs' legacy..

<comment><USER3> _Apple will produce a TV itself and remove this product from the market_

The current Apple TV exists as a low cost way of encouraging people to buy movies from iTunes. There's no way they'd get rid of that.

<comment><USER2> Perhaps. But I think you have the economics backwards. Apple has said before that they break even from iTunes. iTunes exists as a low cost way for them to sell more devices.

Apple has a history of simple product lines. Supposing apple did release a tv, how would it make any sense to have a product called "AppleTV" that isn't a tv? Maybe you're right, but I stand by my own estimation.

<comment><USER4> No, they can't kill off the AppleTV with it's current form factor. They can create a TV, but the current form factor (headless) will remain. If they did, the Apple TV initiative would fail.

And I'll explain why. Just like Apple had to support Windows with their product lines, an Apple TV has to support other TVs. People like to forget that the first iPod didn't support Windows. Also consider that AppleTVs do their part in helping to sell devices. Right now, it's $99 to buy a device to extend the usefulness of my other devices. If we turn that around and I had to spend $2000 for a full blown TV just to put pictures up there? Yeah, not going to happen.

Can they release a TV? Of course! Will they rid themselves of the Apple TV as it stands? No.

On a side note: > Apple has said before that they break even from iTunes. iTunes exists as a low cost way for them to sell more devices.

Yes. And remove iTunes from the picture and the whole ecosystem there, and see how many iPhones or iPods they sell. People buy these devices _because_ of iTunes.

</comment></comment></comment></comment><comment><USER5> I get the feeling we are going to get these type of stories for the next several years. "Steve Jobs wouldn't have done that" or "Steve Jobs didn't like that" will be a pretty good link-baited headline.

He assembled a good crew of people who are going to do some things different (e.g. charity contributions). Some of the things might have been left as "notes / advise" by Steve Jobs in his last days and some might be new thinking. We won't really know the whole story.

Apple changes every day is the only constant.

</comment><comment><USER6> The new UI is temporary just like the previous ones have been. There have been at least 3 major redesigns of the UI so far. They change as needed to introduce new features. The current design is to make room for third party content & services. In this sense the current generation Apple TV is just a place-holder for a future product. Apple has said as much by referring to it as a hobby. What they are doing is laying the groundwork for this future product. AirPlay, iOS Remote, 1080P video, third party services with sign-up and payment, iCloud, etc. The current generation Apple TV is almost just a public beta test of these technologies. When they are ready to do the 'real' Apple TV they will introduce an entirely new UI to go with it.

This sort of public R&D isn't what Apple normally does but I think the challenge of building this product requires it. They need to soften the ground a bit. Of course other companies are working on the same things which helps too. People are comfortable with IPTV services. Current residential broadband can keep up fairly well with good 1080P video. The more SmartPhones and tablets sold the closer we are to ditching a dinky multi-button remote control in favor of multi-touch control. The integration with the cloud for re- downloading content and interconnecting different devices solves a ton of usability problems. Step by step each one of these changes are laying the groundwork for something bigger.

</comment><comment><USER7> The Apple TV had numerous different UIs over the years, so it's safe to conclude that Steve Jobs also said yes to a UI in the past that he should have thrown out.

Steve Jobs mad numerous false calls over the years. He can be wrong, you know.

</comment><comment><USER8> The Apple TV seems to be moving toward an app based approach, so perhaps this UI simply makes more sense in the current ecosystem.

<comment><USER9> When the Apple TV gets apps I think we will start to see the beginning of the end for Nintendo... thats the iPod for on the move and the Apple TV for the home casual gaming..

You can buy a wii game for £40 or almost 80 59p silly games on the Apple tv... and using iphones / ipod touches as an additional controller...

<comment><USER10> With AirPlay Apple TV has apps right now.

[http://firemint.com/2011/guide-to-setting-up-airplay-and- par...](http://firemint.com/2011/guide-to-setting-up-airplay-and-party-play/)

<comment><USER9> But you still need a device to stream it to... I've been looking for a way of running our conference using apple tv's I'd love to be able to send all the keynote presentations to the apple tv without having to have a device to stream them..

</comment></comment></comment></comment><comment><USER11> It's known that Jobs wasn't always right and employees actively did things away / around him that were right.

If Steve Jobs had his way keyboards would have no arrow keys.

I'm glad my Mac has arrow keys :)

</comment><comment><USER12> I found the new Apple TV UI to be a significant improvement, for what it's worth.

<comment><USER13> I find it a mixed bag. I think I navigate it faster, but it is a grid of random technicolor barf.

They should take the next step, let me exile the stuff I never use and bump up the size of the stuff I do use, or open an App ecosystem and let me add more stuff that I do want to use.

Unrelated speculation: The Apple TV has been repeatedly characterized as a "hobby" by Apple. I'm sure they'd love to distribute all major TV and movie content, but they can't get the content owners in line. But what happens now if they do get the content owners to agree to the business model of being paid by happy consumers? The Apple brand is so aglow, and the cost of the AppleTV unit so low, that the demand could go from near zero to internet crushing levels in a matter of weeks. They may have lost the luxury of a controlled ramp up.

</comment></comment><comment><USER14> It's interesting -- I've been living in a furnished rental in Hawaii for the last few months where I have a very small TV (maybe 22"?) and I've had my Apple TV hooked up to it since I got here. Before the update, I found it very hard to read the menus across the room, but I do think the new design is much better for smaller screens. I have a feeling the giant blocks would irritate me if I still had my 60" plasma ( _sob_ I miss that TV) but for a more modest screen, it really makes life easier. Ideally I'd love to be able to mirror the menus in the Remote app so that I don't have to squint to read the Netflix reviews and descriptions.

</comment><comment><USER15> Jobs threw a lot of things away that may have been sufficient, but always wanted to push for even greater implementations and innovations in new products/services.

</comment><comment><USER16> I haven't used the latest iteration of the AppleTV UI, but I did use the last version, and I found it to be pretty terrible. Any time text input was needed, it was a nightmare.

I don't know if the new UI took care of that problem, but coupled with the remote (clearly a case of aesthetics chosen of utility), I found the entire experience to be decidedly less enjoyable than any other living room interface - XBox360, PS3, or any cable set top box.

<comment><USER17> You can use your iPad / iPhone for text input -- but that isn't what this article is addressing. They moved from a text menu type selection system to a grid of applications type system.

</comment></comment><comment><USER18> I really like the new design, but I want folders so I can put all the sports junk that I don't subscribe to away in a corner.

</comment><comment><USER19> Here's the follow-up article on TechCrunch talking with the guy who tweeted this explaining why the fact Jobs threw away the UI isn't such a big deal: <http://techcrunch.com/2012/03/24/jobs-apple-tv-margolis/>

<comment><USER20> Seems like a very long leap from "Now there is nobody to say 'no' to bad design." to "The new UI is no doubt cleaner, simpler, easier to use, and more in line with the now-popular iPad UI and Lion's Launchpad." If I weren't wearing such a well-constructed tinfoil hat I'd say that someone got a call from an Apple legal employee who wasn't happy to be working on a Saturday.

</comment></comment><comment><USER21> For those not sure what the new UI looks like, there's an image here [http://www.cultofmac.com/155915/steve-jobs-hated-the-new- app...](http://www.cultofmac.com/155915/steve-jobs-hated-the-new-apple-tv-ui- but-apple-changed-it-anyway/)

</comment><comment><USER22> Isn't Apple TV one of the less successful Apple products? Some may even say a rare flop(by Apple standards).

The bar is very high for Apple products. The iPod killed the CD player. The iPhone revolutionized the phone market. But the Apple TV? It's yet to cause much disruption.

<comment><USER6> Hard to say. I think Apple said they sold 3 million of them last year which would make it very successful within the tiny dedicated IPTV set top market. It's not really a finished product yet. The current Apple TV is like the Motorola Rockr. A hint of things to come but definitely not ready to make a big splash. It's interesting to note though that NetFlix says they stream more video to Apple TVs than iPads. So something is definitely starting to happen here but I think we're still a couple of years away from the Apple TV really being a mass market device.

</comment></comment><comment><USER23> He also threw out the concept of native apps until he changed his mind she he saw it made sense.

</comment><comment><USER24> knew it.not really. it just looked odd</comment>


Tell HN: PG's 6 Unexpected Advantages of "Cheapness" in a Startup - <AUTHOR>

Preface: So this afternoon I had the opportunity to attend a session at TiEcon on early-stage funding, in which Paul was a panelist.
Here's his list of 6 unexpected advantages:
1. You don't have to spend a lot of time raising money.
2. You are forced to grow a culture of efficiency within your company.
3. The only way to impress somebody is to build something great.
4. You don't attract the wrong type of people (the ones who are obviously only in it for the money)
5. You can't buy things so you're forced to build them.
6. You can't afford to hire someone to do sales. You have to do it yourself, which forces you to interact with the end-user. <comment><USER2> There is a logic in this. The trick to understand it is to place intellectualism ahead of capitalism. It was not long ago when the Internet belonged to those who just wanted to exchange information. Kids and grown ups with no money, only their knowledge and creativity have become very successful. A lot of start-up companies started with little or no money only to become a "blue-chip" in relatively short time. A fine example is Razorfish.

</comment><comment><USER3> In what situations is it worth to buy rather than to build?

<comment><USER4> Big, Good things. Amazon S3 and Google Maps API are the only real ones that come to mind. You couldn't do either of those better if you tried.

It's the Big, mostly good things that are the most dangerous. Off the shelf Content Management Systems come to mind as the obvious example. They'll get you close fast, then morph into a soul-draining time sink as you try to get that last 5%. You'll know early on that you're on the wrong path, but it will likely be six months of torture and waste before you actually scrap it and build your own.

</comment></comment><comment><USER5> I especially like #4...

Technically, #1 is possibly the only incorrect one on the list. If you don't have any money, you are quite likely to try to get some, or at least obsess and waste a lot of time worrying about money.

#6 is so important... It's one of those truths that you only understand after it happened to you once. Until it hits you, you just think "yeah, sure, I know my customers alright".

</comment><comment><USER6> At what point does hiring make sense or when does hiring not fit being cheap? It seems that you often want to stay cheap by not hiring, but if you are behind on the tech, and need it to be further along to answer questions about your business does it make sense to hire earlier and answer those questions... or try to find other cheaper ways to get those answers with out having a fully developed product.

</comment><comment><USER7> I actually think #1 is accurate – if you don't have any money, and you're already working on your product, then you obviously aren't burning through tons of cash just to stay operational. If developing your product is eating through cash, you have to keep spending time trying to raise more to keep going, instead of working on your product.

</comment><comment><USER8> "If you don't have any money", then "you don't have to spend a lot of time raising money"?

Am I the only one baffled?

<comment><USER9> It was about the advantages of running a startup cheaply, not of having no money. And if you're running a startup cheaply, you don't need to raise as much.

<comment><USER10> The one big disadvantage I see is that you can quit pretty easily. Being poor gets tiring pretty quickly, especially if someone waves a nice fat salary and benefits in front of you.

<comment><USER9> This is one of the reasons the young and the nerdy tend to have an advantage in starting startups. They have inexpensive tastes. So they feel prosperous on an income that would make someone older and more conventional feel poor.

<comment><USER10> We're talking about smart people and inevitably they're going to look at friends who've opted for the corporate world and do the math. Certainly as long as the promise of a big payoff is there, then the math might weigh in favor of doing a startup. But it also might not. That whole time value of money thing says that sacrificing income in your twenties is going to hurt you a lot more in the long run than sacrificing income later on.

edit: Of course, right now the "whole time value of money" is basically negative. ;-)

<comment><USER11> Coming from a "poor" entrepreneur who has previously held six-figure software engineer salaries, I can say there's more to entrepreneurship than salary. When I busted my ass working overtime to add cool new features, nobody cared. The company doesn't care, the boss doesn't care, your coworkers don't care either. If I have to spend 1/3 of my life at work, I might as well be doing something I love, even if it puts my retirement at risk.

<comment><USER10> I mostly agree. But there's something to be said for retirement.

<comment><USER12> You can retire well even if you only make $10 an hour for 40 years. It just requires you to be very frugal with your expenses and investing wisely. Let interest do the heavy lifting for your retirement :)

<comment><USER13> The interest rates here are pretty much zero ...

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> It seems easy enough to agree that running a startup cheaply is good. However, seldom are people quantitative about what is cheap. Any chance we can get some numbers? What's a cheap burn-rate for a startup with 3 founders? 3 founders + 3 employees? ...?

<comment><USER15> People are quantitative when they do their business planning. In this context cheap is when cash flow is running close to break-even or better. If you have employees without revenue, it's probably not cheap. If you'll need employees for an extended period before getting significant revenue, you'll need to figure out how to convince investors to open their wallets first.

</comment></comment><comment><USER16> As to the disadvantages of not needing money: there's no immediate incentive to focus on making money. Which means you often spend months/years just building cool stuff that's useless.

<comment><USER13> You can only do that if you have money. Otherwise you'll die of starvation.

</comment></comment><comment><USER17> there is a difference between "cheapness" and "having no money." points #5 and #6 (at least as worded above) indicate having no money, which is fine, but it seems to me that the best place to be is to have money but to be cheap.

there are times when money is very helpful, the trick is to have the money but only use it when it is really needed.

having no money is just the simplest way of forcing a startup to be cheap, but that is not necessarily the best state for a startup.

</comment><comment><USER18> The answer to "buid or buy" is more nuanced than "always build".

<comment><USER9> Yes: the answer is that building almost always turns out to have unexpected advantages.

<comment><USER18> This is silly. You did not build your own laptop or your own accounting system, operating system or your own relational database. There is a crossover point somewhere where building makes more sense than buying, but finding that point is a delicate task for each business, a lot more complex than "yeah, just build it whatever it is".

<comment><USER9> I didn't say the advantages always outweigh the disadvantages, just that there are usually more advantages that you'd expect.

<comment><USER18> I see. In that case why did you label your post as "answer" to "build or buy" question?

<comment><USER9> Because that is the more nuanced answer to "build or buy?" Of course you don't always want to build. But in borderline cases, err on the side of building, because there are often hidden advantages to building.

Are we clear now? Are you convinced I'm not advocating making your own electric power generation stations?

<comment><USER18> Yep, it's clear what you meant now.

I think this was a terminology misunderstanding - I don't see it as "the answer". "The answer" in my book is specific for each particular situation and your _guideline_ is important to take into account for each such situation. I'm splitting hair now, but only to illustrate the source of misunderstanding.

To advance the state of the art it would help if you created a list of cases where "build" produced unexpected advantage and a list of cases where it backfired. At least it would work better for me to calibrate properly.

EDIT: It just occured to me that you answer to my answer is what curried function is to a function result. Throw in lazy evaluation and the line gets blurry. :-)</comment></comment></comment></comment></comment></comment></comment>


Pitfalls to avoid when designing forms - <AUTHOR> http://blogoscoped.com/archive/2008-08-25-n60.html <comment><USER2> For the reset button problem, why not have a reset button that saves the information (client-side), resets the form, and shows a new "Restore" button that does the obvious thing?

Of course it only works with Javascript so the static version could use a smaller clear button or no clear button at all.

<comment><USER3> Saying 'Restore' is not actually obvious - restore what?

Undo maybe, but then I'd expect it to undo a piece at a time.

Put a onClick="confirm(...)" on the reset button maybe, if you feel they'll loose a lot of work.

<comment><USER2> You're telling me the user will press Reset, see the form cleared and the new Restore button immediately appear, and not figure out what it means?

And I'd say the Restore feature (or you can call it undo) is better than a confirmation. The confirmation is annoying if you really mean to clear the form and ineffective to prevent data loss (how many times have you regretted performing some action right after it's too late?).

<comment><USER4> I don't see why you need a reset button at all.

I don't think I've ever gone through a form and decided at the very end, after filling everything in, that I needed to just do it all over again with completely new values in every input box. Can you think of an example where you really needed it and wouldn't just refresh the page?

<comment><USER5> For a consumer-oriented website, I think you're correct. If you're filling out the form as a one-time thing I don't see the reset button's usefulness. Probably a cancel button which takes the user to some previous step would be better.

But if this form is part of an enterprise or small-office intranet application, and that's a form you fill out many times a day, perhaps 100s of times, then the form reset button might come in handy.</comment></comment></comment></comment></comment>


Evidence of freshwater lake that could have supported microbial life on Mars - <AUTHOR> http://www.wired.co.uk/news/archive/2013-12/10/curiosity-mars-lake

<comment><USER2> Title is a reach. What about this lake made it especially appropriate for supporting life? Nothing that any body of water would have. More accurate: 'Evidence of freshwater lake; water is essential ingredient in supporting life'

<comment><USER3> Neutral pH, fresh water (not brackish), moderate temperatures. That's pretty exceptional anywhere in the Solar System that isn't Earth.

</comment></comment><comment><USER4> Given RNA molecules we find on crashed asteroids, I think it is foregone conclusion that at very least there was once microbial life on Mars.

<comment><USER5> We've found RNA on asteroids? Not just amino acids?

<comment><USER4> RNA molecules, not strands.

</comment></comment></comment><comment><USER6> Does anyone know whether Curiosity has the tools/systems to detect whether life exists on Mars _now_?

<comment><USER7> Officially, no it wasn't built to detect life.

But there _are_ cameras all over the thing.

So if something is scurrying around leaving tracks or skeletons, we should be able to see that just fine.

Or if it rolls up on a flower or a tree, _that_ ought to be pretty obvious.

<comment><USER8> A bit trickier with _microbial_ life, though. Though it wouldn't be impossible for it to bump into a stromatolite, say.</comment></comment></comment>


ActiveRecord Race Condition - <AUTHOR> http://pezra.barelyenough.org/blog/2007/11/activerecord-race-conditions/ Favorite comment:
The Rails validations (especially the ensure_uniqueness_of) in my mind are purely for nice error messages 99% of the time. As well as race conditions like you discovered, they are inefficient - if you have a heavily inserted table, then Rails has to select to ensure uniqueness, and then insert - if you just put a unique constrain on the table and do the insert, you save on the select. This would only ever be an issue in a very heavily inserted table that has a unique column, which is probably rare!
-----
I love when something being "probably rare" is justification for it being significantly broken. <comment><AUTHOR> Favorite comment:

The Rails validations (especially the ensure_uniqueness_of) in my mind are purely for nice error messages 99% of the time. As well as race conditions like you discovered, they are inefficient - if you have a heavily inserted table, then Rails has to select to ensure uniqueness, and then insert - if you just put a unique constrain on the table and do the insert, you save on the select. This would only ever be an issue in a very heavily inserted table that has a unique column, which is probably rare!

\-----

I love when something being "probably rare" is justification for it being significantly broken.</comment>


Trolls Just Want to Have Fun [pdf] - <AUTHOR> http://scottbarrykaufman.com/wp-content/uploads/2014/02/trolls-just-want-to-have-fun.pdf

<comment><USER2> Abstract:

"In two online studies (total N = 1215), respondents completed personality inventories and a survey of their Internet commenting styles. Overall, strong positive associations emerged among online commenting frequency, trolling enjoyment, and troll identity, pointing to a common construct underlying the measures. Both studies revealed similar patterns of relations between trolling and the Dark Tetrad of personality: trolling correlated positively with sadism, psychopathy, and Machiavellianism, using both enjoyment ratings and identity scores. Of all personality measures, sadism showed the most robust associations with trolling and, importantly, the relationship was specific to trolling behavior. Enjoyment of other online activities, such as chatting and debating, was unrelated to sadism. Thus cyber-trolling appears to be an Internet manifestation of everyday sadism."

</comment><comment><AUTHOR> In spite of the somewhat whimsical title, it's an interesting paper, and the lead author has published a fair amount.

[http://buckels.psycstudies.com/about- me/publications/](http://buckels.psycstudies.com/about-me/publications/)

Maybe this is a better link to the paper?: [https://pdf.yt/d/XgRRo4fT7qzp9bic](https://pdf.yt/d/XgRRo4fT7qzp9bic)</comment>


Kim Jong-il tweet: South Korean Park Jeonggeun held - <AUTHOR> http://www.bbc.co.uk/news/technology-16852438 <comment><USER2> It's starting to become par for the course for "the good guys" (at least in US geopolitics) to find ways to put undesirables in prison. This used to be reserved for oppressive regimes - Iran, China etc... It worries me not for my own safety, but for stability of these countries (including the US). You start putting your own nationals in jail on bs charges and you end up turning the country against the regime.

<comment><USER3> This is not "starting to become" for South Korea. The fact of the matter is that South Korea is far more democratic now than it was during the Cold War. These laws restricting the dissemination of North Korean propaganda have been in place for decades, and were often used with the tacit approval of the US in years past to suppress dissent.(In fact, until about ten years ago, it was technically illegal to import Japanese pop music into South Korea!)

The only difference now is that their use is becoming increasingly controversial. This, at least, is a good thing.</comment></comment>


8chan Explained - <AUTHOR> https://www.vox.com/recode/2019/5/3/18527214/8chan-poway-synagogue-shooting-christchurch-john-earnest <comment><USER2> Not much to explain. Many moons ago, SomethingAwful was founded by a bunch of people that nobody wanted around. Some years later, 4chan was founded by a bunch of people that even nobody at SomethingAwful wanted around. Some years after that, 8chan was founded by a bunch of people that even nobody at 4chan wanted around. It's the dregs of the dregs.</comment>


Divvyshot Might Just Be The Most Gorgeous Photo Sharing Site Yet. - <AUTHOR> http://thenextweb.com/apps/2010/02/19/divvyshot-gorgeous-photo-sharing-site/

<comment><USER2> congrats!</comment>


Second Life Architecture - The Grid - <AUTHOR> http://highscalability.com/second-life-architecture-grid <comment><USER2> It's interesting that everything that happens in one area on the SL map is processed on the same server.

Since everything processes there, "bad neighborhoods" could arise; the sort where every resident has a ton of poorly-written scripts and a ton of object prims floating around... That area would be noticeably slower than an area on the next server where there might be an SL HOA, mandating certain behaviors.

<comment><USER3> Heh, this has already happened, either intentionally or unintentionally.

See the screeshots in "Second Life uses MySQL" where you see tons of spheres flying around: I haven't been on in years, but I remember there were various devices people made to spawn thousands of objects at once and crash servers (or "sims" as they are called).

</comment></comment><comment><USER4> It appears that SL has had its growth significantly affected by the credit crunch:

<http://secondlife.com/whatis/economy-graphs.php>

I'm not saying it definitely has been.</comment>


Ask HN: Educational resources for a developer who recently started a firm? - <AUTHOR> What educational resources would you suggest to a developer who started their first web design/development firm yesterday?<p>Bonus Question: If you have experience starting a web development business while being unqualified and under-funded, what would you say to this developer if you were their bestfriend? <comment><USER2> Basic accounting and taxes. You probably will have an accountant but it good to understand when tax payments will happen, how to lower profit (to pay less taxes), what's deductible. Already prepare for the situation when customers will be late on invoices, e.g. ask for half up-front payments or other arrangements.</comment>