nz

The possible perspectives that strategy games offer to players is vastly under-explored. Most assume that you control a drone-like army of soldiers, for the sole purpose of defeating an opponent. The Paradox games add much more nuance to this formula, but there is still a vast domain-space in the genre that is unexplored. For example, I'd like to see a game designed primarily around espionage and class warfare -- you cannot control or deploy armies directly, but you can build a network of allies, and use it to (attempt to) bring about changes in policy and dynamics.

Victoria II and III are headed in that direction with the POP mechanics, and modeling the ever-expanding reach of media in the 1800s (there is a reason that most countries centralized on a single national language for the bureaucracy).

But yeah, the only reason we haven't seen a credible Cold-War-era strategy game (aside from that one ancient Mac OS game) is because the era involved very little direct military conflict, and game-publishers have not yet figured out the mechanics of how to model a very nuanced conflict like that in a fun way.

Related to inventing, reinventing, and adopting-the-already-existing:

Alan Kay on inventing the future: https://www.youtube.com/watch?v=id1WShzzMCQ

Jonathan Blow on "reinventing" your own game engines: https://www.youtube.com/watch?v=SOtxjOLst2k

Related, Jonathan Blow on custom vs 3rd party engines: https://www.youtube.com/watch?v=SOtxjOLst2k

Yep, which creates a first-strike/second-strike trade-off. If you have enough resources to click-up an age (or to research some tech-upgrade), you have to choose whether to do _that_, or to build up your military. If you choose the latter, you are implicitly trying to cripple/destroy your opponent before they attack you. If you succeed, then well played. But should you _fail_, you have a huge problem.

The interesting thing is that the first-striker's failure implies that the opponent had built himself up enough to survive the first strike. Which implies that their economy was not vulnerable to the first strike, and might also be capable of launching a second-strike soon.

As a kid, I never really _understood_ decisions like Pearl Harbor -- classic first-strike/second-strike tradeoff example -- until I played this game.

In a similar vein, Age of Empire 2 had a very interesting resource-balance that few other games have managed to replicate. With 5 resources (food, wood, gold, stone, population), and each of those resources being good for very different things (i.e. gold for stronger attack units, and stone for static defenses), and with the population being capped at 200, it presents the player with very interesting choices that have ripple-effects down the line. The sequels didn't quite manage to pull this balance off. And the dynamic is very different from other classics like Civ or Humankind, because those games about geographic control instead of worker-management.

Hoping someone undertakes a formal study of game-balance and economics in various strategy games (to help us make better games).

Previous discussion: https://news.ycombinator.com/item?id=27439240

Finally a comprehensive write-up about the crypto-space that involves careful reasoned analysis of the interests and motivations of the participants in the crypto-space. Addresses some favorite questions like the nature of money and property -- and how most of it is imaginary (like most things about the human experience).

The first section talks about property-records as being kept in a database, and it also talks about villages maintaining "in-memory" property records (in a pre-literate time). A cool method that humans have developed for durable record-keeping are Rai-stones.

Here are some of my note on those, in case we have any anthropology nerds lurking:

Rai Stones are variously-sized -- 3.5 centimeters to 3.6 meters in height -- circular, stone disks with engravings. They are used as currency, decoration, jewelry by the Yapese people of the Yap islands in micronesia. Because some of them are gigantic and weight a few thousand kilograms, they are difficult to transport. To facilitate easier transactions, the Yapese maintain a ledger -- via oral-tradition -- of who owns which fraction of which Rai Stone, not unlike a blockchain.

An interesting case of the use of the ledger to establish ownership over a stone, is when one of these massive stones was being transported by a ship, and the ship sunk into the middle of the pacific. It was never seen again, by any other human being -- it might not have even survived as a single piece -- yet, its ownership is still recorded in the ledger.

In principle, if all of the stones disappeared from the face of the earth, the oral ledger would still contain a list of who owns what.

Crypto-currencies can be considered as digital Rai Stones -- the value is in the ledger not the actual artifacts.

Ref: https://github.com/interlock-network/knowledgebase-public/bl...

Dankon por cxi tio. Mi kutime uzas la vortaro cxe https://vortaro.net, kaj via vortaro estas pli rapida kaj pli ergonomia ol tiu.

It is not _too_ surprising, since Esperanto also shares some coincidental features with Chinese -- its regularity makes the word-building process similar to Chinese. Perhaps poetically, the regularity of roots and affixes does for the arbitrariness of word-building (compared to the lexicons of European languages), what a phonetic alphabet does for the arbitrariness of writing (compared to logographic scripts used in East Asia).

Worth checking out: http://claudepiron.free.fr/articlesenanglais/westernlanguage...

I have written some (obscure) open-source software and have contributed to open-source code-bases. I can say that if you are doing it for some kind of recognition, then you are doing it for the wrong reason. I _do_ think that you (and many others) would be worthy of recognition and appreciation, but most people are far too busy optimizing their careers and chasing the dollar to actually invest the time and effort needed to share some of the spotlight with you. Also, so much of our (humanity's) software stack is open source that we would need to share the spotlight with hundreds of people out there.

Most people write open-source for material reasons -- it lets them bring some of their own code into a new workplace, with minimal employer resistance. Also, many people will try to open-source the tooling they built at work so that they can then take that tooling with them to a new employer (avoiding the duplication of effort and potential legal issues).

All of the open-source code that I wrote for non-material reasons, I wrote it because I thought it was fun to write, and I open sourced it because others might find it interesting or useful. But I never expected any kind of recognition (let alone compensation).

In feudal Japan, poets would write poetry anonymously (not pseudonymously), and many historians and scholars debate which known poet wrote which poem. The fact that these works of art are not attached to any author's ego or name, does not diminish their beauty after all these centuries -- arguably this characteristic amplifies and elevates the work beyond the history of people, to the history of ideas and concepts. At the end of the day, we are just transient conduits for concepts. The notion that a person deserves to have "more" for their ideas and concepts and artistry, is as shameful as the notion that artists deserve to starve for not slavishly serving the whims of the market.

If you're going to down-vote me, could you at least offer an explanation as to why? As it stands, there's an infinity of possible objections you can have with my comment. It would help to know what they are, so that I can at least _try_ to integrate them into my thoughts and perspective.

In the same way that decaf is coffee without the caffeine, (and phone-sex is sex without sex), pseudo socialism is socialism without genuine socialists. In the USA -- and increasingly in Europe -- we've seen the socialists' ranks get eroded by our societies' blind pursuit of ever-greater profits at the expense of the common good. This has resulted in the subordination of most aspects of life -- including most aspects of political life -- to the central mechanics of the market. Politicians cannot win elections without capital, which subordinates them to the capitalists. This is why they routinely support corrosive policies (like hobbling healthcare, turning a blind eye to the opioid crisis for decades, decreasing taxes, regulatory capture, etc) and oppose policies meant to better the public uniformly (like free healthcare, free education, net-neutrality, higher and transparent taxation, independent and effective regulatory bodies, etc). In short, they are obligated to support policies that will generate profits for their wealthy patrons, at the expense of everyone else.

Socialism is meant to be a counter-force to unrestricted capitalism. America lacks this counter-force. Instead, America has a (so called) Left that is afraid of being branded "socialist". Because they cannot embrace genuine socialist policies for fear of upsetting their very wealthy and powerful patrons, they are trying to win votes by appealing to people's pathological tendency to form rival tribal groups. This is quite the irony, considering that socialism's original rallying cry was the (inherently trans-tribal, trans-national)"Workers of the World, UNITE".

True socialism looks for opportunity in horizontal social partitions (the social classes), whereas nationalism looks for opportunity in vertical social partitions (ethno-linguistic and religious segregations). This is why nationalism is the capitalist class's preferred evil -- it directs the dissatisfaction and anger of the lower classes against each other, away from the wealthy. Both the American Left and American Right are focusing on the vertical (tribal) partitions -- it's just that the Left is very polite and composed about it.

This is what (I believe) the GP tried to imply with the term "pseudo socialism".

It is a way to circumvent the paywall.

Savielly Tartakower's take on the distinction:

"Tactics is knowing what to do, when there is something to do. Strategy is knowing what to do, when there is nothing to do."

In case it is not clear from the title, this is an article about optimizing a BFS implementation in Go.

I guess I shouldn't be surprised that this thread took a political tone very quickly, given that the recent issues of the digest contains reports and speculations of a political nature. It makes sense that people's attention would get consumed by these more recent speculations. After all the digest covers risks that reside in the intersection between politics and technology, meatspace and cyberspace.

However, I would like to try to gently nudge this thread more towards the technological side of that intersection. A long time interest of mine has been technological failure: things like nuclear reactor meltdowns, airplane crashes, bridge collapses, and so forth.

For example, jhere is a link to a piece of the digest that covers exactly this kind of stuff:

http://catless.ncl.ac.uk/Risks/1/1#subj4.1

Sure, it's from '84, but as a software engineer I empathize with all of these (mostly) software related failures, as I have to deal with similar failures on a daily basis -- though thankfully they don't involve and fatalities or injury.

Furthermore I find this digest to be very helpful as an archive of safety related issues over a large span of the history of our field, than of current risks which you can find trending on HN and reddit. I suspect the former is much more instructive since most of that stuff happened before many of us were born -- thus giving us the opportunity to learn from the past with an open mind and free of bias. For example the first few years of the digest covered the SDI which was apparently a hot topic among software engineers in those days, while as present it is (to me) a vague and distant notion barely perceptible -- like a fading transmission.

The digest is heavy with the residue of a rich history, and I hope that we (as in humanity) can give a bit more focus to the past, since it will help us make a bit more sense out of the present.

Other fun things:

John McCarthy of lisp fame was apparently a contributor back in the day: http://catless.ncl.ac.uk/Risks/1/7#subj1

Richard Stallman made an appearance in 1990: http://catless.ncl.ac.uk/Risks/10/20#subj5

As did Bernie Cosell (form Coders at Work by Siebel): http://catless.ncl.ac.uk/Risks/10/20#subj6

And Leslie Lamport, (LaTeX, PAXOS, Turing Award): http://catless.ncl.ac.uk/Risks/10/44#subj1

Julian Assange in 1995 talking about LoadDog (the wikileaks guy): http://catless.ncl.ac.uk/Risks/17/59#subj9

Doug McIlroy in 2005 (of Unix pipes fame): http://catless.ncl.ac.uk/Risks/24/57#subj7

Anyway, hope software engineers on this board will find this historical resource useful, and apologies if anyone got trolled by it.

Found this illuminating interview with Arthur in the ACM queue: http://queue.acm.org/detail.cfm?id=1531242

SmartOS's driver support is being constantly improved, but the improvements are being directed to server hardware (like NICs, for example). So, I wouldn't expect SmartOS (or any illumos distro) to have support for the very latest consumer hardware (like components found in the latest laptops).

I guess it boils down to if you want to run SmartOS as a hobbyist or in an actual DC. I myself got it running on a really old (and cheap) HP Proliant DL360 G6. This involved bypassing the SmartArray and installing an LSI controller, so that ZFS could manage the pool directly. But that was years ago, and maybe you can do better ;)

At any rate, you can check out the following sources related to hardware compatibility:

http://dtrace.org/blogs/rm/2012/05/10/illumos-hardware-compa...

https://www.listbox.com/member/archive/184463/2013/02/sort/t...

https://wiki.smartos.org/pages/viewpage.action?pageId=755673

https://wiki.smartos.org/display/DOC/Hardware+Requirements

They are far from abandoned. In fact they are used in production to power Triton cloud's docker emulation. In fact the latest LX-related commit was made 4 days ago (see the commit history of illumos-joyent linked below).

https://github.com/joyent/sdc-docker https://github.com/joyent/triton https://github.com/joyent/illumos-joyent/commits/master

A strange article. Many of the things cited as proof that the theory has poor predictive power are really dependent on how narrow of a scope you're willing to ascribe to industries and sectors.

For example Christensen stated that the iPhone wouldn't be a disruptive technology because it is essentially a very high end phone. This turned out to be a predictive miss on Christensen's part, not because the iPhone succeeded in spite of being a high-end phone, but because Christensen mis-categorized it: it's a very low-end personal computer.

Furthermore, the article uses the HDD market as an example. It states that 1.8" is not the dominant form-factor today as Christensen predicted it would be (instead 2.5" and 3.5" are). However, the article doesn't state whether the analysis took into account the SSD market (I don't have data on the SSD form-factors but all of my laptops have a 1.8" SSD, for what it's worth).

The main problem with the theory's predictive power is that it hinges on being able to accurately categorize companies/products as being part of a particular _industry_ or _sector_. Where does the cell phone industry end and the personal computing industry begin? Are HDDs and SSDs considered to be in _different_ industries, and why? What about railroads and air travel? The lines between industries are blurry at best.

Obviously everything is connected, and the theory is more about predicting the long-term macro-economic interactions between companies/players and the market. Instead of drawing S-curves and looking at industries and sectors (which are really just arbitrary, imperfect categorizations that don't take overlap into account) one should look at which players are stealing other players' low-end customers. That's likely to be indicative of a disruption-in-progress.

Well if you're storing integers or other other small (8-byte) elements, then sure. But if you are storing pointers to objects, then you'll have the overhead of a load (in the comparison function). If you are embedding the objects, then the larger it is the more "copy-overhead" you will have as you move these large elements around when re-balancing and so on. But I don't have the numbers for this, so it might be insignificant overhead. I have it on my todo-list to benchmark embedded-larger-elements and pointers to those elements. Anyway, just something to consider.

If you're interested in this stuff, you might want to check out the draft paper linked below. It benchmarks performance and memory efficiency of various logarithmic time sorting data structures. It's a work in progress, and feedback is always welcome :)

http://nickziv.files.wordpress.com/2014/02/vis_ds.pdf

Yes, the tone is a far cry from the cool-headed, neutral, sterile aesthetic one would expect from technical or academic writing. However, the article is very informative, and should probably be bookmarked for later reference --- in case one ever has to do this kind of work.

The article may have been written in anger, and thus it provokes anger. Good! Programmers who don't get angry while solving hard, inconvenient, uncomfortable problems are, in my experience, unlikely to truly solve those problems --- sweeping issues under the rug, or passing the problem to someone else is more likely. Anger is a very powerful motivational force if honed correctly, whereas contentment often leads to docility, complacency, and quitting.

I find that problems that make you angry or enraged are simultaneously: important and instructive. Most performance problems (or even multi-threading problems), for example, fall into this category.

Having read the paper, and taking the time to think about the whole 'signaling' explanation for open source, I'd say that in addition to ego and joy, signaling is a major motivator for contributing to open source software. While many programmers may contribute to any arbitrary project because of their interest or dependence on the software, the most effective way to signal your skill as a developer would be to contribute to software that is either a) used by the prospective employer to support their business, or b) developed by the employer himself (likely to support their business).

However, this theory doesn't take into account that one may contribute to an OSS project, because an employer is paying them to do this in the first place. Both employers and employees participate in OSS. Employees want to demonstrate their skill so that they would get employed, while employers want to demonstrate their organization's engineering talent to attract even more talent. The paper seems to assume that OSS signaling is simplex, whereas it is actually duplex. But beyond signalling, an organization open sourcing software can be seen as a way to encourage standardization of that software (Android, WebKit, V8, and in the future maybe Dart) instead of a competitor's potentially closed alternative (which might be more expensive to deploy/port/debug and so on).

Sun Microsystems' open sourcing of Solars and JVM can be seen as an attempt attract more talent to the company (which at that time was fairly unpopular, especially when compared to Google which was an open source darling).

For anyone interested, here is a direct link[1] to the scientific background to Tirole's 'Market Power and Regulation' ideas, which were kindly compiled by the committee. Open source is first mentioned on page 27 (out of 54).

[1]: http://www.nobelprize.org/nobel_prizes/economic-sciences/lau...

From the paper:

Open-source software: The literature on patent races assumes that R&D investments are driven by the traditional profit-motive. However, economists are increasingly realizing that not all new technologies originate in this way. An important example is Open Source Software (OSS), where programmers at many different locations and organizations share code to develop new software. This process was important in the development of the Internet, contributing such software as TCP/IP, BIND, Perl, Sendmail, Linux, Mozilla and Apache. What initially baffled economists was that OSS developers did not seem to benefit financially from their efforts. OSS is, in effect, a public good, which raises the question why OSS programmers contribute voluntarily, without pay, to the public good. Lerner and Tirole (2002) argued that economic theory may, in fact, be able to answer this question. Their main hypothesis is that software developers have career concerns. Contributing to the OSS may be a credible signal of one's programming ability, which may lead to job offers, shares in commercial open source-based companies, or access to the venture-capital market.35 Drawing on a previous literature on career concerns (e.g., Holmstrom, 1982), they argue that the signaling motive is stronger the more visible is performance, the higher the impact of effort on performance, and the more informative performance is about talent. They find support for the signaling motive in four case studies (Apache, Linux, Perl and Sendmail). Subsequent research also found support for Lerner and Tirole's (2002) signaling theory, at least for some OSS projects (e.g., Hann, Roberts and Slaughter, 2013, for Apache). However, programmers seem to contribute to OSS for a variety of reasons, perhaps including altruism. A satisfactory explanation of OSS development may require a mixture of signaling theory and insights, like those of 2009 Economics Laureate Elinor Ostrom, into how cooperative behavior can be supported by norms and other social mechanisms (O'Mahony, 2003).

Unless you are not using the host OS for anything _other_ than virtualization. If the host OS is used to host VMs[1], which are then used for specific tasks (casual browsing, banking, development, etc). Any exploit will be limited to the VM. This would be a pretty solid setup. It is only vulnerable to attackers that have direct access to the hardware, or have the ability to exploit the hypervisor.

[1] in other words if the host OS is used as a hypervisor, or if the host OS _is_ a hypervisor.

The last sentence was cut off:

"... a monopoly on the engineering talent."

They didn't re-implement KVM. They ported it (to the greatest extent possible), because it was already a suitable solution.

I wasn't referring to the KVM port as a solution to an exciting new problem (it was, but a while ago, thus making the problem stale). But it was a much needed solution. I was referring to innovations that originated in the Illumos code base such as ZFS, DTrace, zones, doors, crossbow, ctf, least-privilege, etc. All of these are either unavailable on most systems, have inferior clones (i.e. systemtap, btrfs), or are partially available (the Mac DTrace port doesn't have a complete, systemic scope, due to Apple's classist tendencies, and most of the kernel providers like fsinfo are missing, for example).

Either way, I still maintain that Illumos is a nexus of systems innovation compared to other kernels, based on how much innovative technology originated in the Illumos kernel, before being ported to or reimplemented on other kernels (the Slab Allocator is an example of a technology that originated in this code-base and has been reimplemented on almost all other kernels; ZFS and DTrace are examples of technologies that have been ported over to some other kernels, albeit with less functionality/stability).

Also, the release of Illumos-KVM (among other improvements in the last year) only goes to show that Illumos is still innovating in various ways, while other kernels are either still catching up (I believe that FreeBSD didn't support DTrace'ing userland apps until their 2009 release) or losing differentiators (linux just lost KVM). Seeing as how the Illumos project has quite a bit of engineering talent and corporate investment behind it, I doubt that the rate of innovation will drop below that of other kernels... in fact it might just increase, now that potential contributors know that Oracle/Sun doesn't have a monopoly

You should be! As far as I can tell, Illumos is the only kernel project out there that is solving exciting new problems, instead of reimplementing solutions to old ones.

I already checked it out and the timer probes don't work at all.

On one system, I couldn't even invoke kernel functions.

On another system, the kernel panicked as soon as I executed `stap -e ...`.

Basically unusable, at this point.

I hope it improves because developers on linux could really benefit from dynamic tracing.