sdrinf

IANAL, but this has been discussed a couple of times, most prominently here: https://news.ycombinator.com/item?id=3641312 . Short version: comments are copyright @ their owners, HN has an implied license to republish; other sites do not get implied license by the virtue of commenters _not posting it there_. You will have to reach out & ask each of the commenters directly to ask for republishing permission.

Also note, that despite advice given below by rest of the thread, legal does not care whether you store it yourself, or pull it via API; Copyright / republishing permissions are required for the content either way.

| In the meantime Dropbox's core offering of syncing and sharing files seamlessly as well as providing more security minded options for businesses is something that no one else has quite gotten right.

There is absolutely no mention whatsoever neither in the article, nor in your analysis above about Owncloud.

Owncloud (or any OSS fork thereof) is an existential threat to Dropbox's core offering: while the consumer side is not yet price-competative, it can already be one-click deployed by many VPS providers. And the business case for hosting mission-critical data onsite, or at least own leased equipment & encryption is strong, and enjoys economies of scale.

Extra creditz just published an excellent video on why auto-generated vendor-sellable items lead to hyperinflation under most circumstances, and a few ways to avoid it: https://www.youtube.com/watch?v=sumZLwFXJqE

| When buying from a player, the player bot will try to resell the same item for double the price.

Given this, and assuming auto-buy from vendorbots, I'd predict the second they open the game for auto-grinders (or puppeteered bots) to appear, kill anything in sight, sell stuff, pump any bitcoin any vendorbot might hold, until the game economy holds no more bitcoin. It's probably more CPU-efficient, than mining bitcoin; and there's a manual workforce readily mobilizable for it.

The game looks really promising, and I'd love to grind a few hours in it as it stands, but I'm not sure if dropping a bitcoin dependency into it won't sink it prematurely.

| Finally, understand that your contribution is not "free" for the project. It takes time and consideration to even look at your PR and even more to code review it. The more popular the project, the more true this is.

Understand code interactions: they scale N^2 with each new feature added. Specifically, each interaction your feature has with all the other features has to be coded, and then each new feature might interact with yours. This is the curse of scope freak.

It is the sole responsibility of the PM/owner of the project to select which features worth this.

What you're looking for is called the symbolic grounding problem:

| But as an approach to general intelligence, classical symbolic AI has been disappointing. A major obstacle here is the symbol grounding problem [18, 19]. The symbolic elements of a representation in classical AI – the constants, functions, and predicates – are typically hand-crafted, rather than grounded in data from the real world. Philosophically speaking, this means their semantics are parasitic on meanings in the heads of their designers rather than deriving from a direct connection with the world. Pragmatically, hand-crafted representations cannot capture the rich statistics of realworld perceptual data, cannot support ongoing adaptation to an unknown environment, and are an obvious barrier to full autonomy. By contrast, none of these problems afflict machine learning. Deep neural networks in particular have proven to be remarkably effective for supervised learning from large datasets using backpropagation. [..] The hybrid neuralsymbolic reinforcement learning architecture we propose relies on a deep learning solution to the symbol grounding problem.

Source: Marta Garnelo et al: Towards Deep Symbolic Reinforcement Learning https://arxiv.org/pdf/1609.05518.pdf

Strictly from an insurance business perspective, there are two major problems with this:

* Netsec events are black swans: it's very, very hard to model how often a security breach will occur. One could checklist all the ways by which we know currently sites are getting hacked, and would still have to pay out, _because hacking exploits things we don't already know_.

* When a hack occurs, it can happen at scale. Unlike eg life insurance, where you have a single payout for hard-to-predict events, the better the hack, the higher the potential for damage, and so the higher the total payout.

These two together means an IT-security-insurance company might do well for a few years, then file for bankruptcy at the first event that hits it, due to inability to pay.

This thread might be as good as any to point out:

* There is an enormous quantity of culture locked into Facebook posts

* Since Facebook's graph API have been shut down, there exists no API-based way to export _other people's data_. You can get whatever you personally have posted to FB, but none of what _other people_ have posted.

* Individual posts might be scraped, and present in archive.org ,but people's / pages' indices are not available for non-logged-in users

* Social networks have a typical lifecycle of 5-10 years; and their shutdown can happen in a very short timeframe, see eg. geocities ; but imagine that without any accessible index, making full archiving impossible

* This implies, that if/when FB goes down, so will a major slice of Internet Culture circa 2008-2016

* If you have any suggestions, or partial solutions to this, please kindly post it to http://softwarerecs.stackexchange.com/questions/37036/self-h... .

> There are disciplines that have been teaching concentration for hundreds of years that produce people who can concentrate at will under pretty much any circumstance. To teach beginners they choose a very quiet, distraction-free environment.

Can you point at specific resources (name of the discipline, quintessential book about subject) for learning how to practice deep concentration, even in the face of very suboptimal environments?

| Note that outbash.exe listens on 127.0.0.1, but validates that processes that establish a connection are running as the same user as outbash.exe (this check is implemented starting with version v0.7). Therefore, it can be used on multi-user computers.

(from: https://github.com/xilun/cbwin/ )

So, I suspect this uses TCP & networking to do that; which does work: you can listen to a port in LXSS, and that will be accessible via 127.0.0.1 ;and you can connect to 127.0.0.1 from LXSS, and it will be routed to eg. windows listeners . Above was specifically about process-based signals, and non-network-hacks.

I suspect that might be conemu, and compatibility thereof. Specifically, running the bog-standard bash prompt (with conhost.exe) makes this a no-repro; all keys / arrows works in MC & htop

Screenshot: http://imgur.com/a/5Fcr9

Short summary:

* Ubuntu, and all children apps run under current user's credentials, but are launched under an Lxssmanager servicehost process (as opposed to explorer.exe)

* ProcMon can interact (send sigterm / etc to) unix processes; but as shown on htop, unix processes are not aware of windows ones; nor have I found any ways to send signals backwards

* API compatibility is excellent. Last 2 days, I have re-compiled a full python & elasticsearch & mysql stack into this. Overhead is significantly lower, than any of the virtualization stacks

* I don't use AV tools; however, I suspect they don't check for ELF files. Host system is mounted in /mnt/c , /mnt/d ,etc in LXSS, with current-windows-user creds

* 2-command Sandbox reset: lxrun /uninstall & lxrun /install <- will restore the linux subsystem to factory default

* LXSS root dir (/usr /var, etc) is in c:\Users\$username$\AppData\Local\lxss\rootfs\ ; home is mounted into c:\Users\$username$\AppData\Local\lxss\home\$username$\

And some caveats:

* Filewatching (specifically, inotify_add_watch ) does not (yet) work

* Manipulating files from the host occasionally makes it _disappear_ (??!) from visibility in the linux subsystem. Specifically, git pull from bash, then git update from host makes git update from bash impossible (index file open failed). Same problems with other types of host file-manipulation. This might be due to permissions, or somethings I haven't figured out yet.

Do we have secondary sources confirming this, specifically, lawyers in the case confirming this being brought up as evidence? If so, where is the public record of that?

What are CBSLocal's incentives? Can they push fearmongering without repercussions?

If this story is not true, where should we put the "flag" threshold? What are operational voting with money against stories like this ever, ever making HN frontpage again, and for the "news" industry to structurally reduce unfounded fearmongering?

Writing an open, and distributed web crawler / indexer is a nice programming exercise.

Writing an "objective" ranking function (for any values of "objective") in an open, and distributed manner is structurally not favoured by humanity's current incentive structure. As in:

* a dev team have to agree on signals, and weights: "SERP quality" has dedicated teams of people assigned for specific verticals @ Google; replicating this in a distributed manner will be played politically

* Assuming any significant usage, the second you submit ranking code to public github repo, the algo will be played by thousand SEO scammers to their advantage

* Executing custom ranking function on other people's computer not only introduces security risks, but will have scammers setting up honeypots for collecting other people's ranking signals, and playing accordingly.

Ask the consultant to perform (or at least implement) LTV measurement across 3/6-months stage. Price sensitive bank-account-checking users will act as a canary, and at least in the Boston Globe case, I suspect tactics like these to increase churn by at least as much as they increase conversion (implying the business will only see benefit for the next N month after consultant).

As for trust, the US case is simple: report it to BBB.

| Selling BCC was going to pay for living expenses while we built Starfighter’s first game (Stockfighter) and also pay for some development work to assist with the sale of my other SaaS business, Appointment Reminder.

^^ - you're selling AR as well? Last presentation was showing that to be a profit machine? Would love to learn about the reasoning behind that decision!

IPv6 usage is steadily increasing, currently hovering at 10% globally, and 23% in the US. [1]

This is driven partially by mobile deployments, partially by some ISPs rolling out support. Note, that the IPv4 address exhaustion referred to in the media is IANA-level; top-level exhaustion occurred on 31 January 2011 [2]. Also from there:

* Four of the five RIRs have exhausted allocation of all the blocks they have not reserved for IPv6 transition; this occurred on 15 April 2011 for the Asia-Pacific, on 14 September 2012 for Europe, on 10 June 2014 for Latin America and the Caribbean, and on 24 September 2015 for North America.

None of this impacts end-users, as ISPs have large reserves of non-used IPv4 addresses; and there are multiple mitigation strategies for post-exhaustion periods.

Also note, that even if all IPv4 address would be in public use currently, we still wouldn't "migrate" to IPV6 at-once: seeing how there are roughly ~25 billion Internet-connected devices (and 3.17 billion users) using it currently, migration can't take place overnight. Also note, that "pure ipv6" devices currently would be heavily disadvantaged: the majority of sites & services can't be accessed via ipv6 yet.

A probable migration pathway might be ramping up allocation of IPv6; as usage increases, servers will roll out support for it; which might hit a tipping point (similar to the current "HTTPS for everything") sometime around the 40-50% penetration rate. Once that occurs, ipv6-only users will no longer be disadvantaged; that, along with increasing price-points for dedicated ipv4 address might shift ISPs to start deploying ipv6-only, and use relays to access ipv4 services.

However, even under these conditions, servers will almost certainly will provide v4 access points, for reasons of maximum compatibility, and low cost (relative to all dev, deployment, domain, etc costs).

In conclusion, you can rest safely knowing that the code you wrote will be in use for a long time to come.

[1] https://www.google.com/intl/en/ipv6/statistics.html

[2] https://en.wikipedia.org/wiki/IPv4_address_exhaustion

Script injection (see Comcast a few weeks ago), page manipulation (eg. pointing at download links with malicious side-load), keyword-based filtering (HTTP inspection). If you're using non-default DNS servers, you also get privacy on which site you're reading: all HTTP request headers also get TLS protection, which includes hostname, path, etc. And while outside of Tor, there's no protection for the IP address (so third parties can know you're reading a page on github), "a site hosted on github" encompasses a wide variety of content.

From the bottom of the page:

| Our goal is the creation of a nomadic ultra small graphical desktop operating system capable of booting from cdrom, pendrive, or frugally from a hard drive. The desktop boots extremely fast and is able to support additional applications and hardware of the users choice. While Tiny Core always resides in ram, additional applications extensions can either reside in ram, mounted from a persistent storage device, or installed into a persistent storage device.

A few real-world applications:

* Embedded systems, with storage constraints

* Docker; specifically, minimalistic images: pre-compile your (eg. node.js) app, drop it on top of a Tiny Core kernel, results in ~50-80mb image sizes

* At scale, this might be useful for larger clusters; saving a couple of 100s mbs of RAM might be negligible for single servers, but can add up as cluster scales

Cost of customer acqusition. States have to be bagged one-by-one, each with an insanely long sales cycle, your profits have to cover those nice salespeople's salaries, while leaving you with sufficient profit to cashflow expansion. This is not a dev problem; the sort of orgs which are prepared, and can cashflow these sort of sales simply don't have (nor are they incentivized to have) any dev culture whatsoever.

Is there a checklist available on the settings people might perceive as privacy violation, their operational implication, and howto disable it?

There are very few pieces of information really worthy of deliberate broadcasts across star-systems in the hopes of someone catching it. One of these few might be a full dump of neural vector-states (or functional equivalent thereof), at an appropriately low-level assembly, which when successfully executed, brings not a message, but the messenger itself.

A handful of reasons (disclaimer: painting with very wide brush here, in the hope that you get the strategic picture)

* The desktop market is fragmented. Pick your poison: walled garden with crappy devtools, OSS fanatics who will not pay for software in a million years; or warezing pirates. Note that whichever you choose, your app will still end up on torrent sites ~2 days after release anyways.

* The cross-OS development tools' end results are usually sub-pair, even compared with javascript.

* Desktop usage is, and has been stagnating for a while now; while mobile usage is growing at an incredible rate. Mobile native market is also highly fragmented.

* The lowest common denominator across all of these markets is the web: develop it once using responsive design, run it on everything for at least the next decade, or so.

* People have been voting for this platform with their wallets for a while now; specifically by being unable to pirate web apps.

* The stakeholders in selling AWS are: developers (for whom command line & APIs are the critical part), and business decision makers (who are looking for easy leverage). Neither target group is particularly interested in desktop apps.

* Specifically regarding to their propriatory tech (eg dynamoDB), developing a third-party desktop tool for it is a high-risk-no-reward endavour: you either get traction, in which case Amazon will gladly oblige with an app of their own; or it won't, in which case you're out with $lots$.

Joel Spolsky put it best: "Filling little gaps in another company's product lineup is snatching nickels from the path of an oncoming steam roller." ( http://www.joelonsoftware.com/items/2009/06/10c.html )

On the same general line: given a shell, which could analyze frequency of commands & make intelligent guesses for non-executable / invalid commands ("do what I intended, not what I've typed), I would toss my bash so hard against /dev/null, and salt whatever remained of it's config files.

Mirror for Database Error'd: https://archive.today/D33zV

Chrome.exe ,no, srsly.

Specifically, when doing deep infodiving, it's not uncommon to juggle (that is, actually apply ops within 30-min intervals to) 80+ tabs; 2 visual studio in the background; local number crunching: large-ish data / machine learning sandboxes; one-click virtual-machines ("wonder how this looks like in a mac?"); and the occasional steam round. 2x4 vCPU cores usually humming along at ~10-40%, 20-something GB ram usage, no swap.

These reqs bias me towards performance, even at _some_ expense of mobility.

Use case: Due to moving countries, I've recently dumped my powerhouse desktop ( http://blog.codinghorror.com/building-a-pc-part-vii-rebootin... ), and am laptoping around various places; a lifestyle I will probably continue to do so for the foreseeable future.

There are few, if any, performant laptops, that could get even close to the sort of performance I've used to using that machine. However, as long as deployment time is <~3 minutes, I don't necessarily need it to be a laptop; but can settle a middle road in some variations of these.

| ...by the time the Feds get around to doing that, the market will have likely already made Google's dominance is search a lot less important.

Can you elaborate on how that might happen, operationally?

Synthesis: Chrome Security Team would like to put :( for all non-secure HTTP connections. With gradual deployment, and increase of all active sites moving to HTTPS, it is assumed that users won't become trained to ignore this as a warning signal.

| Then, in the long term, the vendor might decide to represent non-secure origins in the same way that they represent Bad origins.

The biggest disadvantage of the proposal, as it stands in current CA climate, is that it's psychologically successfull deployment will impose a liability for site operators to touch their sites at least once per CA renewal timeframe. There are many sites where this isn't desired, feasable, or even possible at all, but which despite non-security, still serves giant heaps of high-quality information. So, this will increase SEO, and accessibility gap between sites run by geeks, and sites (attempted to) run by everyone else. Whether this is a desired future of the web is left to an exercise for the dear reader.

Ironically enough, sub-second music IP rights swap between the shell corps, so as to dodge any lawsuits getting anything out of them.

Worked great too, unless you discount the whole "convert the earth into computronium" in later chapters implying it's origin from the same subsystems.

In lieu of writing an in-depth answer, I'd refer to a previous thread instead: https://news.ycombinator.com/item?id=1726795