Magnasanti: The Largest and Most Terrifying SimCity (2010) - <AUTHOR> https://rumorsontheinternets.org/2010/10/14/magnasanti-the-largest-and-most-terrifying-simcity/ <comment><USER3> Not to anywhere near the level of this but i've been playing a map on city skylines where i've been trying to make it as dystopian as possible, though at first I was just trying to model my city, the sad thing is, on a superficial level, it still resembles it.

Industrial areas lined with low income housing. A whole neighbourhood with schools next to oil refineries, a prison island that receives its drinking water from the sewage run off of the rest of the city, I created roads and bridges everywhere, there's several 'nice' areas along the non polluted areas of water with large mansions, there's a big bustling urban center full of office buildings and highrises not far away from squat, squalid apartments underneath highway overpasses, schools next to landfills, a lack of hospitals and fire departments, many police departments, i've intentionally clearcut as much of the forest surrounding the city as possible, the next step was to create a small gated community out away from the city, for those with money who can't handle the horrid amounts of traffic and infrastructure...

I may have also accidently poisoned the whole city briefly when trying to build the prison island and killed 30% of the people there, but things have been looking up, population growth is finally starting to rise again, though the health of the population is questionable.

<comment><USER4> Sim City 3000 might be the pinnacle of "Sim Cities" when it comes to the feeling of making a big scary city.

I would rather play Skylines than 3000 today due to nice feeling and the roads, but the limit that 6 squares depth from the road is as far as housing will "grow" and that you can't make deep neighborhoods or more angled zones, is a sour thumb for what would otherwise be a perfect game. 3000 neighborhoods felt deep and the isometric view didn't make me sad about not doing angled zones.

If Skylines could make roads free of the square course why not the buildings that seem to have to be orthogonal to the tangent of the road.

<comment><USER5> Sim City 3000 is my favorite too for all the same reasons and I really wish SC3U shipped with multiplayer like the leftovers suggest it would have: [https://tcrf.net/SimCity_3000_Unlimited/Unused_Multiplayer_T...](https://tcrf.net/SimCity_3000_Unlimited/Unused_Multiplayer_Text)

<comment><USER6> Looks like the commands for an IRC client, I wonder if they were intending an in-game community based on IRC?

I'm not sure it indicates actual multiplayer capabilities, or just the intention. It just looks like someone dropped an IRC client library into the repo at some point.

Totally speculation of course, but maybe even just a dev tool in the repo that got sent around to different devs/studios so that they could communicate. Slack being IRC for work wasn't a new concept after all.

<comment><USER5> Compare to [https://simcity.fandom.com/wiki/SimCity_2000:_Network_Editio...](https://simcity.fandom.com/wiki/SimCity_2000:_Network_Edition) for the precedent

<comment><USER4> Interesting.

"The server does not automatically pause when all players are logged out."

So you were supposed to like log in for 30 min per day and play a little and then wait for tomorrow with the game server running? Seems like a Minecrafty way of playing. It would probably be fun for some IT-department to have an instance but it feels very niche.

<comment><USER6> It used to be pretty normal for someone in a friends group to run "the server" I think, for whatever game it may have been. Often just from a PC on their home network. I don't think it would have been a stretch, but it would have definitely been niche.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> I think it's important to remember that a "system" in a video game is a work of art just like the game itself. The systems, in a lot of ways, reflect the ideas and thoughts of the authors of that game. Magnasati's highlights and flaws help illustrate that thinking, or what tax rates are best for doing well in the game.

An example that comes to mind is Factorio, where solar panels are more tricky to operate than generators, but minimize conflict with the ingame fauna. Earlier versions of Rimworld were programmed to have men be either gay or straight, but women to be bisexual. I think both of those gameplay mechanics illustrate (or at least point to) the author(s) idea about the world.

<comment><USER8> > I think both of those gameplay mechanics illustrate (or at least point to) > the author(s) idea about the world.

For good games, I don't think so. The #1 concern of any video game is "is it fun??".

Case in point: Factorio oil is infinite and a renewable resource (pumpjacks never run out). This isn't there because of some preconceived notion of infinite oil. This mechanic exists because planting new pumpjacks is far more annoying than planting iron mines / coal mines. In fact, pumpjacks are basically the only endgame mine that cannot be automated with blueprints.

As such, its best to have pumpjacks pump infinite oil for the rest of time. Because it'd be too an annoying of a game if oil ran out.

\</comment></comment><comment>----

In the case of Factorio solar vs nuclear vs coal: the game developer made them different enough to make the difference fun to think about and fun to play with. But I don't believe it necessarily reflects upon the political opinion of the creator.

<comment><USER9> Huh? Pumpjacks give less oil over time. They never really run out, but eventually you'll stop running regular trains to an oil depot because your reservoir tanks take hours to fill. Unless you have a small base and dozens of oil fields, you could never run on depleted fields alone, and thus you're constantly needing to expand and seek out more oil fields (just like the other resource types) mimicking the way that maintaining fossil fuel based industry requires continuous petroleum exploration.

<comment><USER8> > They never really run out, but eventually you'll stop running regular trains > to an oil depot because your reservoir tanks take hours to fill.

Speed beacons + Speed Modules + Infinite Productivity gets you pretty far.

> Pumpjacks give less oil over time.

Back in 0.13, they dropped to 0.1 oil/second. Today, this minimum has been grossly buffed, greatly reducing the number of depleted pumpjacks you need in endgame. The output is also improved by infinite-productivity research, increasing their output the longer your megabase runs.

There's also Coal Liquefaction, which came a few years after 0.13. That also reduces the need to find new pumpjacks (and again: because coal mines use electric mines, its possible to automate mines with blueprints).

So Coal runs out, but is far easier + automatic to expand compared to oil. So you just turn your coal into oil products.

</comment></comment></comment><comment><USER10> I think we can often get sucked into optimizing our life to limit the possibility of negative surprises - predictable reliable employment, reliable transportation, go-to meals, healthy habits that work for us - and then we can often end up in a reality where things are stable but potentially boring or soul-crushing. That's what the essay reminded me of - even if the city were ruthlessly efficient but with a nice park and bodega and deli in walking distance, it could still feel similarly soul-crushing. So I've been trying to think more about how to leave more room in life for "positive surprise" but that's kind of a difficult thing to optimize for. I'm open to ideas anyway!

<comment><USER11> Go new places, explore! Doesn't have to cost money or be a big deal - <USER2> your neighbourhood/area/town on foot or bike.

Or maybe Micro Adventures: [https://alastairhumphreys.com/microadventures- landing/](https://alastairhumphreys.com/microadventures-landing/)

</comment></comment><comment><USER12> (2010). I distinctly remember the discussion from two years ago: [https://news.ycombinator.com/item?id=16933265](https://news.ycombinator.com/item?id=16933265)

<comment><USER13> Same here. Can't really forget the city once you've seen it.

</comment></comment><comment><USER14> The image reminds me of Guangzhou, China. I recently looked at google earth images of Guangzhou. I then looked at images of New York City. It is incredible to me that we in the U.S. think of New York City as a sprawling metropolis when not far from the city center it is mostly single family homes on plots of land. Whereas Guangzhou has many more high rise buildings for miles and miles. Get the ruler in Google Earth and check it out.

<comment><USER15> How many of those are actually occupied?

<comment><USER16> it's a false narrative that these cities are not occupied - i think you'll find that the CCP plans for decades, and the population growth of china will fill those apartments in time.

<comment><USER17> That explains that there are plans for future occupation, but does not support the claim that it is a false narrative that they _are_ unoccupied.

<comment><USER16> > does not support the claim that it is a false narrative that they are > unoccupied.

no the false narrative was that they will remain unoccupied and is just built as a form of economic stimulus.

</comment></comment></comment></comment></comment><comment><USER18> Alphaville (circa 2000) forever rules as sim-anarchy's crowning achievement. Without moderation it quickly became saturated with the worst crimes people can come up with.

The Alphaville Herald was dedicated to it; the blog continued on for years, after the sim was shut down. This Salon article references the mag [https://web.archive.org/web/20040217030353/http://www.salon....](https://web.archive.org/web/20040217030353/http://www.salon.com/tech/feature/2003/12/12/sims_online_newspaper/index_np.html)

Alphaville is one of my favorite pieces of internet history but it wasn't ever really documented. It's hard to find anything about it now.

<comment><USER19> I've never heard of it before, but the Alphaville Herald and all of its archives are still online: [http://alphavilleherald.com/archives](http://alphavilleherald.com/archives)

<comment><USER18> Nice. Thanks!

</comment></comment></comment><comment><USER20> There are no transportation issues because there is nowhere to go because everywhere is the same.

</comment><comment><USER21> Reminds of the person who played a single Civ II match for 10 years.

IIRC it ended with the Celts, Vikings, and Sioux facing off in thermonuclear war in the year 3991.

[https://www.reddit.com/r/gaming/comments/uxpil/ive_been_play...](https://www.reddit.com/r/gaming/comments/uxpil/ive_been_playing_the_same_game_of_civilization_ii/)

[https://www.reddit.com/r/theeternalwar/comments/uyswv/here_i...](https://www.reddit.com/r/theeternalwar/comments/uyswv/here_it_is/)

</comment><comment><USER22> Is this using the SC erasing exploit?

There's a bug that lets you delete a building tile but keep the building there in memory, meaning you can build over it but have all the same pops/crime/etc.

Lots of megopolis SC maps use this exploit.

<comment><USER23> He says in the video that he uses no cheats.

</comment></comment><comment><USER24> Magnasanti seems like a more tangible application of the AI paperclip maximizer. A city built to maximize population reduces the pleasantness of each life.

</comment><comment><USER25> I'm surprised no one's mentioned that this is more or less a stochastic cellular automata.

It's essentially a grid-based parallel computer.

</comment><comment><USER26> To quote the article:

Population growth is stagnant. Sims don't need to travel long distances, because their workplace is just within walking distance. In fact they do not even need to leave their own block. Wherever they go it's like going to the same place.

\</comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>-----

Maybe OP posted this after working from home in quarantine for one week too many.

</comment><comment><USER27> Anyone else here play foundation?

[https://www.youtube.com/watch?v=UqZWxCv-_5I&list=PLIsqJzeZeG...](https://www.youtube.com/watch?v=UqZWxCv-_5I&list=PLIsqJzeZeGYEEho6ysI91Jprx-i6HWj96)

Interesting game to max out, not sure if anyone has tried though...

</comment><comment><USER28> In a some tangential way this makes me think of Derek Parfit's "repugnant conclusion":

[https://plato.stanford.edu/entries/repugnant- conclusion/](https://plato.stanford.edu/entries/repugnant-conclusion/)

</comment><comment><USER29> Curious to why it is called "Magnasanti"; possibly related to Arcosanti [0]?

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

</comment><comment><USER30> It is also a Civic in Beyond Earth. [https://civilizationbeyondearth.gamepedia.com/Magnasanti](https://civilizationbeyondearth.gamepedia.com/Magnasanti)

</comment><comment><USER31> Kind of surprised that pollution is a problem with no roads and no industry.

<comment><USER32> Densely packed skyscrapers block wind maybe?

</comment></comment><comment><USER33> Magnasanti in Italian sounds like "Saints' Eater". Poetic, isn't it?

</comment><comment><USER34> Wonder if we'll ever get planet scale Simcity for sweet Ecumenopolis planning.

</comment><comment><USER35> as a purist sim city 2000 player, i love this</comment>


Tech giants collaborate with the EU and UN to censor speech globally - <AUTHOR> https://youtu.be/tPZvic7e4I0 <comment><USER2> I'm unsure about the point that's being made here. Yes, EU regulation can affect American consumers, but it's been the other way around for decades. _Lack of regulation_ , or regulation that Europeans disagree with, has affected us on a US-centric internet. letting hate run rampart but censoring a mother breastfeeding her baby has never made a lot of sense to me, but I had to live with it.

The solution is straight-forward. Most of the tech giants are American, so if Americans disapprove of EU regulation creeping in, they can tell their companies, through legislation or however else to respect American law, and when those companies operate in Europe or somewhere else they provide services in accordance with local law. It's more overhead for tech companies, but that's how every other industry works. Then everyone's sovereignty is respected and we don't need to stumble over each others toes.

</comment><comment><USER3> This is such a hairy problem. On the one hand, the simplistic libertarian argument—"Private companies don't have to host content they don't like, period!"—fails to convince because of the special legal status enjoyed by online platforms due to the CDA. On the other hand, it's definitely not a straightforward first-amendment issue, because the first amendment is explicitly narrow: it bars congress from passing laws that restrict free speech. Perhaps the best argument I've come across is that private censorship is an issue of civil rights, rather than constitutionally-guaranteed civil liberties. The legal justification for, say, not allowing businesses of public accommodation to discriminate based on race doesn't come from the constitution. Nevertheless, only a few on the far right want the CRA to be repealed.</comment>


Back to Microsoft: Using Windows again so I can use Linux effectively - <AUTHOR> https://blog.eldrid.ge/2020/01/13/back-to-microsoft/ <comment><USER2> So how exactly is using the WSL using Linux more effectively ?

Is that not the same as claiming that : Using Wine so I can use Windows more effectively ?

I'm really not sure from your article what you were missing, on either Windows/Linux side.. You didnt mention any Windows/Linux specifics, just that you tried the WSL and it worked. Which is cool..

But if you're just worried about using linux more effectively.. Just use linux ?

<comment><USER3> As he said:

" I began looking for dockable tablets with USB-C and the ability to do Linux work on them while also having good battery life, and relatively painless wifi and bluetooth. While there are some great preloaded Linux devices out there (e.g. Dell XPS, System76, Purism Librem) all either lacked a tablet mode, USB-C , or both. Macs lacked tablet mode, and also have been using a keyboard design recently that I don't personally like very much."

None of the OOTB Linux laptops offered either a tablet mode, usb-c or both, same for the Mac. The clue was in the content.

<comment><USER2> Yeah I kinda get it now, but it's still a bit strange for me. I've never shopped for an OOTB linux laptop, nor do I understand why thats a requirement, gnome as supported tablet mode for years too. So was all a bit confusing what the relevance of those 'clues' where.

<comment><USER4> Not everyone wants to spend time on setting up drivers and figuring out why something no longer works after an update, even if they have the skills. I can setup Linux on almost any HW, I choose not too, and use Mac and Windows instead because I have better things to do with my time. Out of the box hardware works out of the box and allows you to do something you actually enjoy. If you enjoy setting up and maintaining Linux, by all means, you should do so, but other people have other hobbies.

Mind you, it's not like MacOS or Windows are a joy to setup either, especially on obscure hardware, but if you buy first party hardware, that hard work is usually done by people who get paid to make it their full time "hobby" so I don't have to.

As an example, there is a YouTube dude who does nothing but installs Linux distorts. He is an expert VIM user even though he doesn't code, just edits config files and plays in the terminal while looking super serious. I spend time in VSCode writing actual code. It's less cool looking but far more productive for me to use MacOS for that. To each their own.

<comment><USER2> > Not everyone wants to spend time on setting up drivers and figuring out why > something no longer works

Cool, for starters, linux is not like that anymore, I remember setting up BSD from a copy from a magazine, that's not how it is today thank god so that point is as useless for this context.

> it's not like MacOS or Windows are a joy to setup either, especially on > obscure hardware

Ok; now we are loading full OS's up,(on obscure hardware?) bit of change of focus from your last comment. But whatever. Nobody in their working mind needs to load up a bootstraped OSX+n so unless you're a complete pirate who requires sketch, you better have a hook and an eye patch before i'll entertain your fallacy. Windows is super easy, maybe more than your mom, as we're all throwing ideas out?.

Your last one is kinda too comical to make fun of..

> As an example, there is a YouTube dude who does nothing but installs Linux > distorts. He is an expert VIM user even though he doesn't code, just edits > config files and plays in the terminal while looking super serious. I spend > time in VSCode writing actual code. It's less cool looking but far more > productive for me to use MacOS for that. To each their own.

Yeah, to each their own. But, we're talking about one article, one very specific article, actually, we are again talking about 1 article. Not examples.

But, this was fun. Moron.

I'll be sure to take all your comments/nonsense with a glacier of salt.

If you'd like some attention for your work, do something and share it, the OP had the balls to do write something and accept my criticism, where is yours ? You're a bit worse than that little shit i take after I've taken a shit.. The inconvenience.

</comment></comment></comment></comment></comment><comment><USER5> I'm a heavy UNIX user and believer. I hate Windows enough to have run it inside a VM on Linux, taking the pains to set up GPU passthrough so I can get graphical acceleration without ceding control of my computer to Microsoft.

But that was on a desktop. And although the Year of the Linux Desktop may very well be upon us, I have to agree with the article.

There is a lot of really powerful, really slim, really convenient hardware that can't easily be used with Linux. I'm planning to buy a laptop soon. It's not going to be a Thinkpad.

Can someone provide a counterpoint to this article, perhaps in the form of a convenient tablet-like machine (like a Surface Pro) that can run Linux without too much hackery? I'm willing to compile kernels if that's what it takes. But I would like for those things to eventually work once I do.

<comment><USER6> You might have some deeper reasons other than those described in your comment, but I genuinely don't understand why you would vehemently oppose robust hardware, which not only enjoys industry wide acceptance, but also provides the most favourable conditions for running *nix, modding and upgrading. Instead, you have cornered yourself and seek an inferior alternative solution, without wanting to get your hands dirty ─ which consequently makes your life even harder?

<comment><USER5> I want something I can easily carry with me. You're not wrong in that it's mostly impossible to modify these devices, but I don't think being able to mod these devices really provides you with a ton of lift anyway.

And I'm okay with getting my hands dirty, but I'm just one person with hopes and dreams. Maybe I can write _one_ kernel module but I don't think I could build everything needed for a comfortable experience.

</comment></comment></comment><comment><USER7> WSL 2 is better in very critical ways. WSL 1 occasionally corrupts SQLite databases. It's a problem for anyone, but especially if you use Nix, where an SQLite db is a single point of failure. I had it happen to me.

On the other hand, WSL 1's network interface is the machine one, and WSL 2 is a VM. So X server setup is a bit more tricky.

Windows Terminal does not support the mouse — no easy Vim window / tmux pane resizing. I use WSLtty (but haven't managed to set it up to render emoji. )

It's a bit difficult to maintain configs for everything to work in WSL, on macOS, and in Linux.

<comment><USER8> After spending half day trying to get CygwinXFree and XMing to work _properly_ , I just realized it's never going to be better, on Windows.

<comment><USER7> I'm mostly fine using native GUI apps. Not like I use much except a browser, messengers, and Office.

VcXsrv was largely painless, as far as I remember.

<comment><USER8> VcXsrv works without pain! Thx a bunch!

</comment></comment></comment></comment><comment><USER9> one thing about the tablets with detachable keyboards i don't like is the kickstand is the only way to prop up the body. that makes it tough to use one from your lap for example. i realize there are 2-1s (i.e. laptops that have a hinge) but i wish there were a tablet with a detachable keyboard that could prop up the tablet using a hinge. the problem of course is the keyboard aren't rigid themselves so you can't hinge anything from them.

<comment><USER10> I think you're looking for something like the Surface Book: [https://www.microsoft.com/en-us/p/surface- book-2/8mcpzjjcc98...](https://www.microsoft.com/en-us/p/surface- book-2/8mcpzjjcc98c)

<comment><USER9> like i said i'm familiar with 2-1s that fold over. what i'm looking for is a case like this

[https://www.amazon.com/dp/B01C7AU8IY/ref=psdc_11548963011_t1...](https://www.amazon.com/dp/B01C7AU8IY/ref=psdc_11548963011_t1_B01AWGYT0I)

but for my dell 5285 (basically a surface)

<comment><USER10> The surface book has a removable but rigid keyboard. So, it seems to fit the criteria. Am I misunderstanding your criteria?

<comment><USER9> oh interesting. sorry i didn't realize the keyboard was removable on the surface book. that is in fact what i was imagining. thanks!

</comment></comment></comment></comment></comment><comment><USER11> +1 for the Surface Pro 7. I recently bought one as a companion for my mb pro (still the daily driver) and I love it. Windows 10 is not bad either.

</comment><comment><USER12> No amount of cool hardware or linux integration will ever cause me to run Microsoft's spyware OS ever again.

<comment><USER13> In many corporate and enterprise environments it's a requirement for the desktop. At a previous job I had this limitation, though all my work was managing their few hundred Linux servers. I used VMware Workstation to keep my head in the Linux environment, and because a proper bash and vim and ssh is my minimum. Now, I would use WSL2, as it's more than up to the task, and noticeably faster.

As for the Surface, I bought my wife a Surface X for Christmas, so of course my trusty Yoga needed depot repair right as she got it. She was kind enough to let me take it for the couple of weeks it's been away, and I went through the process of upgrading it to 10 Pro, installing WSL2, etc. It works mostly well, except for Docker.

There's not a functional Docker for ARM64 unless I build it myself, which I haven't felt a strong enough desire to do. But, the tablet itself is nice, once I got used to the smaller keyboard.

<comment><USER14> If you use WSL2 you can use the version of Docker packaged for your Linux distro instead of using the Windows Docker, you have to start dockerd yourself but then it Just Works

<comment><USER15> Are there ARM64 binaries for docker? What about all the common images, they come in arm versions too?</comment></comment></comment></comment>


Equity to developers - <AUTHOR> http://chrischandler.name/entrepreneurs-regarding-equity-to-developers

<comment><USER2> Does this extend to partnering?

I'm working through my network to find a programmer that I would be comfortable partnering with on a startup. Am I going to be insulting him/her if I can't pay them? I would expect to split the company with him or her if he/she agreed to team up.</comment>


Monorepos and the Fallacy of Scale - <AUTHOR> https://presumably.de/monorepos-and-the-fallacy-of-scale.html <comment><USER3> Whenever I hear smart and reasonable people argue well for both sides of an engineering issue, my experience is that it will turn out that we're arguing the wrong question. The perspective is wrong. We can't get past thinking in terms of our old terminology.

What we all _really_ want is a VCS where repos can be combined and separated easily, or where one repo can gain the benefits of a monorepo without the drawbacks of one.

Another crazy tech prediction from me: just as DVCS killed off pre-DVCS practically overnight, the thing that will quickly kill off DVCS is a new type of VCS where you can trivially combine/separate repos and sections of repos as needed. You can assign, at the repo level, sub-repos to include in this one, get an atomic commit hash for the state of the whole thing, and where my VCS client doesn't need to actually download every linked repo, but where tools are available to act like I have.

(This will also enable it to replace the 10 different syntaxes I've had to learn for one project to reference another, via some Dependencies list and its generated Dependencies.lock list.)

In a sense, we already have all of these features, in folders. You can combine and separate them, you can make a local folder mimic a folder on a remote system, and access its content without needing to download it all ahead of time. They just don't have any VCS features baked in. We've got {filesystems, network filesystems, and VCS}, and each of the three has some features the others would like!

I don't have much money right now but I'd pay $1000 for a good solution to this. I'd use it for my home directory, my backups, my media server, etc.

<comment><USER4> I don't think it is quite a revolution from/killer for the DVCS as you think. A lot of what you ask for can be done with DVCS tools if you go low level enough. The git graph supports more complex shapes in the raw than the git UI tools ('porcelains') tend to make it easy to work with. Especially when you throw in new tools like GitVFS for virtualizing some/all of the git object database. To some extent what you ask for is simply a UX problem in the DVCS world of how to make such power available in an easy-enough to use way, without providing too many additional new footguns.

> Whenever I hear smart and reasonable people argue well for both sides of an > engineering issue, my experience is that it will turn out that we're arguing > the wrong question.

Right, though my feeling is the root underlying discussion is actually sociopolitical rather than technical. The preference between monorepos and polyrepos seems more to do with the organizational structures of organizations and _people_ than about the actual technical merits of either approach. I think the issue is that developers just feel safer trying to tie things to technical merits than engage with the problem at a sociopolitical level.

<comment><USER5> > tie things to technical merits than engage with the problem at a > sociopolitical level.

This hits the nail on the head. The real advantage of monorepos is that they are _reproducible_. Many-small-repos aren't. A monorepo, ideally one like bazel[1] pushes will produce the same bitstream every time you put "make".

Projects terminated, going in a different direction, servers moved, down, forked, ... it all just doesn't matter. _Your_ stuff works. Network or no network.

The problem is that these repos allow programmers to be very undisciplined in a way that sabotages projects. In a monorepo _you_ are updating libraries. In every individual project. That's a big plus, when it comes to "my software works", but of course it is work. Your software doesn't suddently stop working, but that's _because_ it doesn't change, which means it won't change unless you make it change. Which means, new database driver ? You're upgrading it. No apt-get, no sysadmin deploying a shared library or dll install doing it for you.

There is always a _strong_ drive by higher up programmers and managers to fix "undisciplined" programming, and ... I've never seen this work. Or at least, I've never seen this do more than move the problem.

The thing I don't understand about some languages, like Golang, is the (ridiculous) insistence on hermetic binaries (not using anything on the system, not even libc), and yet their very strong insistence on non-hermetic source (even to the point of sabotaging the tools for people who wish to do it, and sabotaging to some extent the community to achieve this). Either do one, or the other. I feel like C/C++'s support of both approaches is a superior option. You want shared (nobody does, but hey that's my opinion) ? You can do that. You want everything hermetic ? Not a problem.

In my opinion sharing things between projects is a mistake.

[1] [https://bazel.build/](https://bazel.build/)

<comment><USER4> There are just as many tools for reproducible builds of polyrepos, between various package management strategies and CI tools.

> Projects terminated, going in a different direction, servers moved, down, > forked, ... it all just doesn't matter. Your stuff works. Network or no > network.

I think it becomes a forest/trees thing. People that prefer a monorepo are most focused on the forest, and people that prefer polyrepos are most focused on the individual trees. The end goal is usually the same (a healthy forest), and done right both approaches are generally isomorphic (the "canopy" of the forest looks generally the same to the users either way).

To push the metaphor perhaps to the breaking point, a lot of the arguments between monorepos and polyrepos break down into management of the "root system" in the forest. Monorepos often don't care as much how deeply the roots are entangled between trees so long as the forest is healthy, and polyrepos tend to encourage a more "bonsai" approach of tending to each tree on its own. Either way, it rarely seems to affect the "canopy" (end user experience) of the forest, but can matter a great deal to things like technical debt and project management structure and project deadlines.

</comment></comment></comment></comment><comment><USER6> While certainly interesting, the article leaves out the juicy bits monorepos and their workflows offer:

\- library developers can easily see the impact their changes will have on their consumers

\- library changes that introduce regressions in their consumers can be caught pre-merge given good test coverage

\- dependency version updates between packages cause less mayhem because they are performed atomically and only merged when green

At the same time, many drawbacks are also left out:

\- the incentive to have long living branches for stability reasons can negate most benefits mentioned above

\- build times for compiled languages can become problematic even for moderately sized organizations (I'm looking at you, C++)

\- in my experience, you pretty much need a dedicated dev team working on workflow tooling because ready solutions are fragmented and hard to integrate (code review, merge bots, CI/CD, ...)

<comment><USER7> You list three items here:

"- library developers can easily see the impact their changes will have on their consumers

\- library changes that introduce regressions in their consumers can be caught pre-merge given good test coverage

\- dependency version updates between packages cause less mayhem because they are performed atomically and only merged when green"

But I think these are actually signs of big failure modes of monorepos, and each one has analog for solving it with polyrepos and/or versioned artifacts that's actually much safer and more practical.

Firstly, wishing to see how library changes will cause issues in downstream consumers is often a sign of very deep problems, because the library designer should be free to make changes or enhancements as they deem necessary to solve the problems they need to solve, which may require validating new changes don't introduce unexpected problems for consumers, but, critically, also _may not_ involve that, and in fact the usual case should be that it doesn't involve that.

Instead, it's up to consumers to consume versioned artifacts of the library (more on this in a moment), so that consumers are totally in control of "opting in" to new changes. If the consumer doesn't want to opt in, they should not be forced to (e.g. in monorepos where a successful merge of library X is a silent, de facto upgrade for all consumers required to consume library X from the same commit, etc.)

Instead, the consumer should be the one creating an experimental branch with the intended version upgrade, and running it through the consumer's validation tests to see if opting to upgrade the version will work.

If it fails, they can open a bug report, and the library maintainer will decide if that regression is now necessary because of a constraint in the new version's design, or if it can or should be patched.

To be clear, this all should be happening inside a monorepo or outside of one, truly doesn't matter. The point is to get rid of the horrible practice of forcing de facto software upgrades on one section of the code merely via a successful merge in a another section. That idea is terrible in concept, a very misguided thing that shouldn't be desired.

Instead, when you merge library changes in one part of the monorepo, CI or other tooling should produce a fixed artifact from it, like a Python wheel, jar file, Docker container, shared object binaries, whatever, and automatically upload to an artifact store like artifactory, with versioned identifiers.

The code in some other section of the monorepo then can just happily keep plugging along, not blindsided by new changes, hit by errors uncaught in testing, etc., and the maintainer of that code can plan for their version upgrade according to their own timeline and testing.

In particular, this is what actually reduces "mayhem" as you put it in dependency upgrades, because the standard of doing it implicitly when there is a green merge is just a form of putting your head in the sand and acting like the library author can trust green merge status as a reliable indicator that downstream consumers can auto-accept new changes, when really only those downstream consumer team devs actually know if that's true or desirable.

<comment><USER8> >Firstly, wishing to see how library changes will cause issues in downstream consumers is often a sign of very deep problems, because the library designer should be free to make changes or enhancements as they deem necessary to solve the problems they need to solve, which may require validating new changes don't introduce unexpected problems for consumers, but, critically, also may not involve that, and in fact the usual case should be that it doesn't involve that.

One of my pet peeves is when another developer tells me something "should" happen. I know library changes should not cause unexpected problems. The question is _does_ that library change cause unexpected problems. Which is one of the benefits of a monorepo. You can make a library change and with at least some level of backing say that it doesn't break anything.

>Instead, it's up to consumers to consume versioned artifacts of the library (more on this in a moment), so that consumers are totally in control of "opting in" to new changes. If the consumer doesn't want to opt in, they should not be forced to (e.g. in monorepos where a successful merge of library X is a silent, de facto upgrade for all consumers required to consume library X from the same commit, etc.)

>Instead, the consumer should be the one creating an experimental branch with the intended version upgrade, and running it through the consumer's validation tests to see if opting to upgrade the version will work.

The problem is that in an enterprise you will have many things that aren't under active development. So if you rely on consumers to pin a version and then upgrade you might end up with dozens of different versions of a library out there. And then what happens if you find a security issue or something else that forces everyone to upgrade to the latest version? Suddenly you have a bunch of applications that no one has touched for a while that all need to be upgraded.

<comment><USER7> > "One of my pet peeves is when another developer tells me something "should" > happen."

Exactly, like when someone tells you that you should upgrade your dependency simply because some new code was merged.

> "So if you rely on consumers to pin a version and then upgrade you might end > up with dozens of different versions of a library out there."

The same thing happens in a monorepo, usually with dozens of incompatible legacy bundles of feature flags / toggles.

</comment></comment></comment></comment><comment><USER9> The benefits of monorepos (in my experience) are all people/organisation based e.g. it can be easier to enforce standards/processes among 100s-1000s of engineers with a monorepo, or it can be easier to manage/release a very large interdependent codebase/eco-system being worked on/coordinated between dozens of teams.

However, this linked post makes a great point, those benefits are all 'scale' problems which 99.99% of orgs don't have. The corollary is I've seen how hard it is to go from from multi-repo -> monorepo when you reach the scale where you _would_ see some benefit.

I also think that the tooling/UX doesn't publicly exist to solve the multi- repo problem with 100s-1000s of engineers working on 100s of repos. It becomes so hard to navigate, understand and grok and so much is buried in dark corners. My experience is that that tooling is _less hard_ to build around monorepos (Google for example).

<comment><USER10> Interestingly, the article linked here argues that monorepos are good at small scale (e.g., startups) and multi-repos are good at large scale (e.g., Twitter).

The author does not discuss the fact that Google has used a monorepo. (Not sure if it still does.)

<comment><USER11> It still does, while someone might point out that a few percent of Google's code is not in the monorepo, most of it is in the same repo.

</comment></comment></comment><comment><USER12> We are a small 20ish dev company using a monorepo with mostly python. Our tooling is Bazel and Drone.

\- Ease of onboarding. Being able to quickly build or test any target is awesome for the new employee.

\- Ease of collaboration. I can see all of the code easily and can learn from these patterns. I can also quickly contribute or extend apis and fix all usages without concern for breaking changes.

Our use of Bazel quickly gets us around git scale issues by enabling external dependencies that can be loaded into the workspace without fully vendoring everything.

<comment><USER13> That sounds cool. Could you elaborate on this "Our use of Bazel quickly gets us around git scale issues by enabling external dependencies that can be loaded into the workspace without fully vendoring everything."?

<comment><USER14> The other question is: how stable is Bazel and how easy is it to extend and/or find open source extensions for it?

<comment><USER12> We haven't had any issues regarding stability. For the most part we extend by creating additional rules. Many of these are supported by the community(search for bazel and rules_* and you should get a bunch of results on github).

</comment></comment></comment></comment><comment><USER15> I've never understood the debate between mono and multi repos. With the right tooling, the line seems to vanish and you just have folders anyway.

Each repo may have their own policies and permissions, which is the biggest reason I see to keep them separate, but again the distinction still seems little more than a folder.

Am I missing something?

<comment><USER16> In my case, I'm struggling to find good tooling to support monorepos. We're running a microservice architecture, but our CI is triggered by GitHub web hooks. Currently we're either doing a full build of everything on each webhook event or we're doing some error-prone git-diffing to try to make sure we're only rebuilding when necessary. I've looked at tools like Buck and Bazel, but they seem really heavy for our ~30 person engineering team and they also seem to have odd ways of doing things (no support for pulling from a package repository, vendoring is assumed to be vendored--which incidentally the author of this blog post characterizes as a Bad Thing). Folks who are using monorepos successfully--what tooling do you use to solve these problems?

<comment><USER17> make solved dependency resolution for partial rebuilds over 30 years ago. There has been lots of improvement since. I don't doubt you have a real challenge, but the problem comes from some immature tool in your toolchain (that I'd be willing to speculate is because someone decided only Javascript tools are interesting after 2010, because reimplementing features classic tools is more fun than learning old reliable tools), not an aspect of the monorepo.

<comment><USER16> How does make solve the problem of only building what has changed in the current PR? It seems like this would only work if you have a single CI server and all of your artifacts live in the filesystem on that server, no? Solving that seems sufficiently difficult that saying "make solves the problem" seems disingenuous, but maybe it's easier than it appears to me?

</comment></comment></comment></comment><comment> grey-area We're pretty small scale (< 20 services, < 10 devs), and happily use a monorepo (recently moved from multiple repos when that became unwieldy as services grew). If you have a lot of services/projects with some shared dependencies they can make tracking that easier. I agree with the article that in general they make life easier.

It depends on what tooling you're using, and whether it is tied to the version control system. Clearly if the tooling makes assumptions about one deployable per repo and works on git hooks that's going to cause pain, but the answer is don't use monorepos if your tooling doesn't support it, or change the tooling so it does.

Most companies won't scale past a few hundred employees, so they're never going to hit any sort of scale issues with monorepos, and if they do, they'll have the resources to deal with it.

Does this have to be a religious war? Does one size fits all really apply here?

<comment><USER18> > We're pretty small scale (< 20 services, < 10 devs)

This is really important and the whole point, indeed.

Eg: We consider our org to be "many repos" (we have several thousands). However, hundreds of them contain 5, 10, or 20+ packages/projects/services. It's funny because we'll talk about creating "monorepos" (plural) for certain part of our product, and it confuses the hell out of people.

<comment><USER19> Several thousand repos - ye gads! How do you document them? How do they fit together? Do they reference each other?

<comment><USER18> The answers to all those questions are "it depends". There's a few thousand libraries, those obviously refer to each other.. Some have readme files and that's enough, some have full documentation "books", some have comments in the code and that's enough.

We don't mandate a company wide development process, so each team and groups can choose their own process and how they track their stuff.

We do have automation and tooling to keep track of things though.

</comment></comment></comment></comment><comment><USER20> The right way to write this kind of content is like Digital Ocean did: [https://blog.digitalocean.com/cthulhu-organizing-go-code- in-...](https://blog.digitalocean.com/cthulhu-organizing-go-code-in-a- scalable-repo/)

Rather than these back and forth about the theoretical implications of a monorepo, actual stories of implementing one are 10x more useful to me.

<comment><USER21> I think there is a balance. It's always possible to argue that DO would have done better or worse with a polyrepo. However if you ignore evidence, then the theoretical arguments can get silly very quickly.

<comment><USER7> Another problem is confusing causal effects from confounders. Did a monorepo _cause_ success, or did they succeed _in spite of_ a monorepo. Studying individual cases for which there could never have been a counterfactual outcome (e.g. FB or Google) literally cannot provide evidence of a causal effect.

<comment><USER21> That's essentially what I was saying. We have evidence that it is possible to be successful with both a monorepo and a polyrepo setup, which is perhaps uninteresting other than to contradict people saying that either setup is guaranteed to be an unmitigated disaster.

We also, however, have subjective feedback from people working on those teams as to how they think it would have been different. It's not rigorous data, but it shouldn't be altogether ignored either, particularly since rigorous data is so hard to come by.

</comment></comment></comment></comment><comment><USER22> > Developers are not arguing children that need to be confined to separate > rooms to prevent fights

Has the author seen the fights that go on? We're extremely opinionated.

</comment><comment><USER23> The original "Monorepos please don't" article really just convinced me how great monorepos are when you _aren 't_ at scale. So you know, put your shit in a monorepo, and then when it gets painful, break it out.

<comment><USER24> That process will take you 3-7 years, depending on how many resources you throw at it. Can your business survive 3-7 years of #seriouspain?

This article hand-waves over many of the criticisms while ignoring a few cold realities. If you're following an infrastructure as code pattern and/or if you run bare metal, at some point you _WILL_ determine that some things are too sensitive to keep in the monorepo. Here is one of the places where coupling will screw you the hardest.

Your lightweight production deployment repo will have a hard dependency on some nightmarish 35-40GB monorepo. Your collaboration tools like rietveld/gerrit will choke under the load and you will struggle to get big enough servers to maintain it. You'll do things like push to one target and pull from another. You'll deal with all sorts of transient failures trying to push or pull. Your CI/CD platform will start taking an eternity to do anything.

Monorepos absolutely result in coupling and coupling is one of those nasty things that you don't realize how much of a problem it is until you're drowning.

None of the above-mentioned complaints are theoretical. I've lived through them all.

<comment><USER21> I imported a 20 year old SVN monorepo to git with 100s of thousands of commits and tens of thousands of branches/tags and it was under 10GB. Removing a few large .tgz files that were inadvertently committed brought it down to 5 GB.

Linux has 25Mloc and ~800k commits; I think the pack is on the order of 2GB?

I don't doubt that 40GB nightmarish monorepos exist, I'm just wondering how and why.

<comment><USER24> Linux is a highly focussed project trying to accomplish a single thing well and with rigorous standards.

If you have 100 developers working average US work schedules and making 5-10 commits per workday (debatable number, depends on culture, but i'm averaging between the "big" commit and lots of small commits), you're going to end up with 100k commits _per year_. And many large startups have a multiplier of that number of developers and they're much, much messier than kernel devs.

Referencing the ideal case as counter-example is a bit silly.

<comment><USER21> So the nightmare monorepos are caused by unfocused teams trying to accomplish many different things poorly?

</comment></comment></comment></comment></comment><comment><USER25> Monorepo vs polyreop summary notes from previous HN discussions: [https://github.com/joelparkerhenderson/monorepo_vs_polyrepo](https://github.com/joelparkerhenderson/monorepo_vs_polyrepo)

I'm adding notes from this HN discussion today. Feedback welcome.

</comment><comment><USER26> Merging/integrating code & styles is difficult and error prone. At the end of the day, if two systems interact they will need to be "merged" at some point. It seems to make more sense to handle this in tests/at a source code level then risk doing it in the runtime environment alone.

I think tooling and granular permissions (still part of tooling) can be blockers, though. It makes less sense outside an enterprise/company perspective such as developing a discrete component that gets pushed to a public repo (Maven, pypi, npm, etc)

</comment><comment><USER27> What are the actually serious downsides of having a repo for each project again? Serious question. Mercurial supports Subrepositories for example. Just define your rules for pulling stuff.

From my own experience, if you are arguing about whether use convention A or convention B, the answer should be to have C that allows both, and then configurations on top of C for A and B.

This applies for example to lookups in the dabatase by an index.

</comment><comment><USER28> > Does the practice of keeping all code together in one place lead to better > code sharing? In my experience that's clearly the case.

This is where abstraction comes in. When done correctly abstractions are necessary so that you can separate your work from things you don't want to work on. In my application I want to be able to access and modify files on the local filesystem. I don't care about the differences between opening files in Windows versus Linux or the intricacies of how filesystems work at the bit level. My application evaluates some code and writes some output to a file. I use Node.js to solve for a universal file management API. This is an example of a good abstraction because the separation is clear and explicit.

The simple rule for abstractions is if you can do the very same job in a lower level you don't need the higher level code. In the Node.js example you cannot access the filesystem in a lower level, because no such standard library exists to JavaScript.

Bad abstractions don't provide separation. Many times developers want to use an abstraction to solve for complexity, but inadvertently do the very same things the abstraction is supposedly solving for just in a different style or syntax. Many JavaScript developers use abstractions to access the DOM or XHR. XHR is simple: assign a handler to the onreadystatechange property, open the connection, and then send the request. You lose huge amounts of performance by abstracting these and dramatically increase your code base and the separation between the API, the framework performing the abstraction, and the code you are writing are all superficial and self-imposed.

By using and enforcing good abstractions while avoiding bad abstractions you keep your application far more lean and restrict the focus of your development team to the goals of the project. Without that your code isn't a monorepo, its a dependent library of another repo.

</comment><comment><USER14> I just have this to say: the discussions here are painfully oriented around SaaS. Once you're doing stuff on-premise or making desktop applications (things requiring long lived release branches), the discussion is totally different.

<comment><USER29> I don't see why shipped software is mutually exclusive from monorepos. You can always check out new subdirectories of repos and treat them as a form of branching where eventually directories are merged together in a separate commit.

<comment><USER14> I find that shipped software actually operates better in a normal, branched monorepo. You just branch the whole thing. The alternative is several repo and using a package manager. That minimizes merging in many branches, as you can just point the package manager at the updated module version, but brings its own hassles.

Either way, as I said, different world from the discussion here, which I'd summarize as "SaaS monorepo vs SaaS polyrepo".

</comment></comment></comment><comment><USER30> I think I can summarize my thinking on this pretty succinctly: I want to build a product, not tooling for software development, and I certainly don't want to spend any time trying to keep different repos synchronized, etc.

<comment><USER7> It turns out that effectively separating dependencies _is a huge part of_ building a product.

This is like saying you really want to swim but you don't want to get wet.

</comment></comment><comment><USER31> I'm part of a company that went from a boring VCS strategy to jumping on the monorepo bandwagon against my advice to keep our git usage simple. It's been fairly terrible - merge conflicts, code going to the wrong environment, nobody can actually do a hot patch, and even long running feature branches which should be stupidly simple run into immense problem.

It also caused issues with our npm repo solution, and has created the worst case of dependency lock we've ever had.

Do yourself a favor and say no to monorepos. It is massive complexity for no benefit.

</comment><comment><USER32> 1\. It's really hard to tell if any of the people writing blog posts about these things have ever experienced the larger scale monorepos or not for any length of time.

As best I can tell, the answer is "no", and they are mostly writing based on perception. They don't appear to even do things like "try to talk to people who have experienced the good and bad of it".

While the writing is fun, it makes it a lot less useful in both directions, IMHO.

2\. The author is right that planning more than 6 months for smaller scale companies makes no sense. However, both of these authors seem to fundamentally miss the actual problem in large companies, which they assume is around engineering and scaling large systems. In fact, it is not. The underlying issue is that engineering a thing is no longer your main cost. This is one of many reasons larger teams/companies are fundamentally different (as this author does correctly point out).

There are 2080 work hours in a year.

If i have 8000 developers, and I have to spend an hour teaching them a new thing, i just spent ~4 people for a year.

If you spend a day teaching them something new, I just spent ~31 people for a year.

If you spend a work week teaching them something new, I just spent ~154 people for a year.

That's just the basic learning costs, it doesn't include migration costs for code base or _anything else_ [1].

But these costs certainly dominate the cost to engineer a solution as you get larger - the systems being talked about here (which _have_ scaled engineering wise) are not 50 people a year (i work next to them :P). Not even close.

In some sense, talking about the engineering challenges makes no sense - <USER2> basically don't matter to the overall cost at large scale.

These same things apply to most of the broader (in the sense of who it touches) pieces of developer infrastructure like programming languages, etc.

As you can also imagine, you can't stand still, and so you will pay costs here, and need to be able to amortize these costs over the longer term. In turn, this means you have to plan much longer term, because you want to pay these costs over a 5-10 year scale, not a 1 year scale.

[1] It also excludes the net benefits, but you still pay the costs in actual time even if you get the benefits in actual time as well :)

Also, productivity benefits from new developer infrastructure are wildly overestimated in practice. Studies I've seen basically show people perceive a lot of benefit that either doesn't pan out or doesn't translate into real time saved. So at best you may get happiness, which while great, doesn't pay down your cost _here_ ;)

<comment><USER17> What is the difference in cost between an 8000-person org all spending a week learning something new, and 800 10-person orgs all spending a week learning something new? it's the same fraction of availalbe time

Large orgs have more resources (revenue) and more costs. What matters is whether revenue:cost ratio is superlinear or sublinear in org size.

<comment><USER32> I'm not sure of your first point. The organizations i'm talking about are clearly agglomerations of teams anyway. Nobody has a flat 8000 person team structure i'm aware of :)

Also, the fraction is not the problem, it's certainly the same. But the absolute scale of the number matters at some point.

0.001 people a year of lost dev time is not likely to change what your company could accomplish.

200 is.

(I think you don't disagree, but i can't really tell, so if you do, let me know and happy to argue about it further :P)

</comment></comment></comment><comment><USER33> This can't really be discussed without also clarifying how your target language and tools ecosystem does package management. i.e. are you expecting to generate and version internal packages and then consume them from a feed?

It seems like, if you don't have this facility then the monorepo becomes more compelling.

Not to mention, are you building 1 or 2 apps, or a whole host of microservices.

Without knowing that, your experience of mono vs. multi-repos won't be much use.

</comment><comment><USER34> I have a simple question: are monorepos possible in git? What is the upper limit of contributions per day for git to be effective in a monorepo?

<comment><USER35> Absolutely. Most monorepos are git.

The entire commit history of Linux kernel development exists as a single git repository which you can check out here: [https://github.com/torvalds/linux](https://github.com/torvalds/linux)

(Indeed, git was developed for this very purpose.)

And it's very doubtful you're going to become larger than Linux. If your company becomes so large that git can't handle all of your code then quite frankly you've exceeded beyond your wildest dreams. Worrying about Google scale for your code repo when you're a startup is the ultimate counting chickens before they hatch.

<comment><USER36> I really wouldn't call the Linux kernel a monorepo. Not compared to Microsoft keeping all of Windows in a single repo.

The problems start when you can't clone the repo within an hour or so, because git doesn't allow partial clones like SVN did.

<comment><USER35> All of the Linux source code is in a single repo. How is that not a monorepo? How are you defining monorepo if not this?

The entire Windows codebase is also a monorepo. It just happens to be a bigger one.

<comment><USER36> I'd define a monorepo as multiple loosely (or un-) coupled projects in the same repository. The Linux kernel is a single strongly coupled project.

Nevertheless, whether or not you should keep your code in a single repository is more a question of the sheer size of the repository than of whether the code logically belongs in the same place.

<comment><USER35> Makes sense.

But yeah, even the total code of all projects combined at a startup isn't likely to get anywhere close to the scale of the Linux repo, so it's at least a good example of how far you can get with a single large git repo (regardless of the relatedness of the contents therein).

</comment></comment></comment></comment></comment></comment><comment><USER37> > Looking at it from the other side, could introducing strict borders somehow > make it easier to reuse logic? I think it's clear that borders can only take > away from your ability to perceive opportunities to use abstractions or to > unify code.

This is not at all clear. I'd argue that a visible organization of your codebase into repositories makes it easier to reuse code in the same way that interface/implementation splits do: it makes it clearer which parts felt domain-specific and which felt like reusable libraries.

> The bottom line is that you should pick the right abstraction and the right > place for a function or class based on the individual merits of the case - > and not driven by facts about repos created a long time ago.

This seems to be assuming that repository boundaries are defined in the beginning and fixed for all time - the same mistake I see opponents of static typing making. Your repository structure reflects your logic and business structure; as those change you change your code structure to match.

> True, touching multiple subprojects in a single commit is not always > desirable. For example, updating backend and frontend components > incrementally in backward-compatible ways can be the better approach. But > even so, it's useful to retain the option of cross-boundary commits for many > reasons including simplicity and enforced coordination.

This needs to be justified. In much of programming we consider the benefits of strict isolation to outweigh the costs - e.g. private fields in OO languages, true parametric polymorphism, microservices. You can't just assert that having the option of bypassing the good practice is worthwhile.

> If you think about it, splitting a codebase into sub-repos is a ham-fisted > way to enforce ownership boundaries. Developers are not arguing children > that need to be confined to separate rooms to prevent fights. With > sufficient communication and good practices, a monorepo will allow you to > avoid the question "which repo does this piece of code belong to?" Instead > of thinking about repo boundaries - effectively a distraction - a monorepo > allows you to focus on the important question: where should we draw the > boundaries between modules to keep the code maintainable, understandable and > malleable in the light of changing requirements?

Communication and good practice are the most costly way to enforce important things; you could equally well argue that e.g. unit tests are a ham-fisted way to enforce non-breaking of code and developers are not arguing children that need to be reminded not to break each other's functionality.

Repo boundaries are higher-level than directory boundaries. No-one is arguing for having each directory in its own repo, but being able to represent "not directly involved, but versioned together" and "separate enough to be versioned separately" is a very valuable distinction to have in your toolbox.

> Many of us, especially in the world of startups, work in smaller teams - > let's say less than 100 developers.

Do you find it practical to communicate and co-ordinate with 100 other developers before making any changes? Because that's the only case where a single repo makes sense - when you are working closely enough with every other developer sharing the repository that you don't need to go to any extra effort to organize who is changing what.

Once you're not attending the same standup, you shouldn't be working on the same repository. You need to have a release cycle with semVer etc. so that people who aren't in close communication with you can understand the impact of changes to your code area. Since tags are repository-global, the repository should be the unit of versioning/releasing.

<comment><AUTHOR> OP here - interesting perspective, especially the parallel drawn to dynamic/static types. Thanks for the thoughtful post

</comment></comment><comment><USER38> Glad you wrote this and saved me the effort, pretty much what I was thinking of jotting down</comment>


Ask HN: What to Do with Stalking Neighbours? - <AUTHOR> Hi,
I'm writing here out of desperation, hoping someone is/was in similar position or just have an idea on how to deal with this. The sonic isolation in the apartment building that I'm in is pretty bad and so about a week ago I noticed that my upstairs neighbours were following me around the apartment and trying to decipher every sound I make with a pretty remarkable accuracy, I can hear them talk but I think they have much more accuracy. I tried to ignore them but they are persistent, I tried to talk to them but they completely denied even hearing anything. To give you an idea, they can tell when I'm in my bed and whether or not I'm sleeping (based on my breathing) they can tell what I'm watching on TV etc. I'm not sure what to do here, with the covid I'm forced to work from home so I'm pretty much living this nightmare day and night 24/7 I'm already not sleeping well, this stress is unbearable ... I'm thinking of involving law enforcement but how do I prove any of this is real?
Thanks for any help! <comment><USER2> Paranoia is common, especially during times of high stress.

People are very quick to leap from paranoia to schizophrenia. Paranoia can be a symptom of schizophrenia, but it can also be caused by other mental illness, or it can exist on its own without a mental illness. This website is pretty good: [https://livingwithschizophreniauk.org/information- sheets/und...](https://livingwithschizophreniauk.org/information- sheets/understanding-paranoia/)

You could try recording what they say, and then comparing your impression of what you hear them say in your apartment with your impression of what you hear them say on the recording.

It's important to get help early.

<comment><AUTHOR> Haha I'm not paranoid guys, I know what I'm hearing!!

<comment><USER2> Whatever you decide to do you'll want to try to get a recording. If you want to get law enforcement involved you'll need a recording. If you want to get whatever your local neighbour dispute resolution process is involved you'll need recordings.

FWIW, most people have a poor understanding of auditory hallucinations. Ask someone to stand behind your back and talk to you. That's what hallucinations often sound like: a completely normal, real, voice that you hear like any other voice.

</comment></comment></comment><comment><USER3> You can prove this is real to law enforcement by recording your neighbors talking and playing back the recording. If you can hear them clearly enough to know that they're speaking _about you personally_ (and not about their own personal business, or something they saw on TV, or about the weather, or the local sports team) it should be trivial to prove.

If you _can 't_ hear them well enough to determine that they're speaking about you, and it's just the muffled sound of indecipherable voices, then you're _assuming_ they're speaking about you when they almost certainly aren't.

Have you brought this up with friends or family? What do they think?

</comment><comment><USER4> Sorry, I am confused, if they deny doing this how do you know they can tell when you're in bed etc?

Your best bet might be a white noise machine or similar artificial background noise (quite music). I used that when I was irritated I could hear my neighbours moving around/talking etc. The good thing about this is it works both ways so you can't make out the sounds they make any more than they can hear you...

It also might be worth checking out reddit.com/r/legaladvice they're pretty experienced and can tell you your rights, how to get them, what to quote etc.

<comment><AUTHOR> I can hear them talk and walk ... imagine being in a sitcom and the narrator is saying everything that the character on screen is doing that's what it feels like.

<comment><USER4> Thanks, that makes more sense. They sound a bit crazy. I'd go with the Music\background noise approach and check with /r/legaladvice to see if they can recommend anything else...

It might be worth recording some of their commentary. If you can do that, you would (I think) have a good case for harassment or similar.

</comment></comment></comment><comment><USER5> > To give you an idea, they can tell when I'm in my bed and whether or not I'm > sleeping (based on my breathing) they can tell what I'm watching on TV etc

To be honest I'm confused. What makes you think they're listening to you breathe?

They've denied hearing you, and it sounds like you're guessing they're following your movements because when you move in your apartment, you hear them move in their apartment upstairs at the same time, repeatedly.

What makes you think they're stalking you? Why would they be interested in your movements?

<comment><USER3> In all honesty, this sounds more like schizophrenia in the OP than the neighbors listening to him breathe to determine whether or not he's sleeping.

</comment></comment><comment><USER6> Turn a radio on quietly to play music in the back ground or leave a television on quietly as back ground noise. Get a fan and let it run 24/7 and the white back ground noise should help.

Troll them and pretend to be on the phone planning murders and drug shipments.

If all else fails, look for a new place.

A buddy use to tell me that his next door neighbor (condo) would complain every time he pissed in the toilet. She said she could hear everything.

Make sure you aren't over reacting?

</comment><comment><USER7> What evidence do you have for them listening/being able to decipher your every move?</comment>


DNA from Neandertal relative may shake up human family tree - <AUTHOR> http://news.sciencemag.org/archaeology/2015/09/dna-neandertal-relative-may-shake-human-family-tree <comment><USER2> So let me get this straight. The whole of Eurasia was already inhabited by human-like creatures as early as 650,000 years ago, but homo sapiens didn't leave Africa until about 100,000 years ago?

<comment><USER3> What's strange about this? Homo sapiens evolved later.

Also the dates depends on your definition of human-like. Homo erectus migrated to Euroasia 1.2 mln years ago already.

<comment><USER2> It's just weird to think that we drove them all to extinction so quickly and so effectively in a relatively short space of time. Long before we had agriculture or non stick-and-rock technology. How did we do it? A few Homo sapiens wander into Eurasia, which already has a population of millions of Homo, and all the other Homos die off?

I'm not advancing an alternative theory or saying its wrong, I'm just saying its surprising.

<comment><USER4> It's also possible that Neanderthals prevented modern humans from leaving Africa until their populations were already in decline for other reasons (disease? inbreeding? infighting? overhunting?). In that case we may have just sped up the inevitable.

</comment></comment></comment></comment><comment><USER5> I like it when things like this happen.

When a new discovery mucks up what was assumed to be established knowledge, it causes a lot of scientists with a stake in either side to push themselves hard to do more research.

Science and society itself benefits.

<comment><USER6> I'm surprised they were allowed to publish. This has been known in some circles for at least a decade, maybe longer.

</comment></comment><comment><USER7> It's funny that we humans think we know things about the ancient past, everything is always a guess with data that we have no concept of how incomplete it is.

<comment><USER8> That's true for history, as well. Archeological digs in the US have rewritten colonial history, and even Civil War history. I've often wondered how much we "know" about history is completely false.

For one small example, some years back, an office building had a natural gas leak, and at one point the roof blew off. (I was a witness.) The fire trucks came, the news choppers, and the reporters on the ground. That evening, I taped each of the local news broadcasts.

Every one of them got the fundamental facts wrong (such as calling the office building a warehouse), the timeline was wrong, etc. But those news reports are probably the only record of the event, and will go down in history as what happened.

Not that what happened there mattered, but it has made me suspicious of the veracity of news reports ever since. It doesn't even have to be malicious, the errors were just sloppy work in their desire to be done with it and move on to the next story.</comment></comment>


Fuzzing is magic – Or how I found a panic in Rust's regex library - <AUTHOR> https://www.nibor.org/blog/fuzzing-is-magic---or-how-i-found-a-panic-in-rusts-regex-library/ <comment><USER2> It's really disquieting how much similarity there is between fuzzing and QuickCheck... and yet _so_ few people have even noticed and know about _either_. (Yes, fuzzing and QC work at slightly different "levels", I suppose, but... it's all just virtual execution by the CPU, so...)

<comment><USER3> Worth noting that there's also an implementation of QuickCheck available for Rust (by none other than burntsushi, the author of the regex library in the OP): [https://github.com/BurntSushi/quickcheck](https://github.com/BurntSushi/quickcheck)

<comment><USER4> We've recently started testing C code via Rust QuickCheck.

In addition to the relatively clean Rust -> C interface it's very nice to have higher degree of compile-time assurance of the correctness of the property model itself. As the models become non-trivial it becomes increasingly difficult to build them reliably in C itself.

<comment><USER5> Do you have more information about that? Maybe a blog post?

<comment><USER4> Not at the moment, but almost certainly at some point in the relatively near future.

</comment></comment></comment></comment></comment><comment><USER6> How does the fuzzer actually work? Is the data really just a completely random string (array of bytes) over and over again, or is there something else? Does it just chose random byte random number of times for each input, or there is some more sophisticated logic in how exactly does it chose the "random input"?

<comment><USER7> libfuzzer (and many of the fuzzers used widely today) is a coverage (as in, code-coverage) directed fuzzer. So it's not just randomly mutating the input, but "selecting" for random inputs that happen to light up new code paths. It works with a (or generates a random) corpus, and prefers the sample inputs that light up new code paths in subsequent mutations of the population.

</comment></comment><comment><USER3> I'm really excited at encouraging a culture of fuzz testing in Rust. :) Can someone explain what's currently Linux-specific about cargo-fuzz? Is it to do with LibFuzzer itself?

<comment><USER8> The libFuzzer website doesn't cite any supported platforms or platform requirements so I think this might just be a matter of someone putting in the effort. The Chromium documentation (where libFuzzer comes from originally) does make it sound like it either takes effort to integrate with various sanitizers or (more likely) requires the infrastructure that the sanitizers do. None of those support Windows and seem to work best on amd64 Linux or, if you're lucky, amd64 macOS.

</comment></comment><comment><USER9> It would be interesting to know how such a panic-inducing bug makes it passed Rust's much vaunted borrow-checker and other correctness validations. Or does the regex library include "unsafe" code blocks?

<comment><USER3> I don't think this comment warrants the downvotes it's receiving, as it's entirely reasonable to conflate panics with unsafety if one is only used to "crashing" in the context of C. It's a misconception that we get relatively frequently, so we may just need to make sure this is highlighted in our official tutorials.

<comment><USER10> We have a whole chapter on error handling in the second edition of The Rust Programming Language[1] that goes into these issues in detail. When we revise chapter 1 (we're doing that chapter last), we're planning on defining what Rust means by "safe".

[1] - [http://rust-lang.github.io/book/second- edition/ch09-00-error...](http://rust-lang.github.io/book/second- edition/ch09-00-error-handling.html)</comment></comment></comment>


We Made a Twitter Bot to Predict the Future - <AUTHOR> http://motherboard.vice.com/read/twitter-bot-predicts-these-futures <comment><USER2> So who will be the next president?

<comment><USER3> Hillary Bush.</comment></comment>


Get Exec to Volunteer for Charity on your Behalf - <AUTHOR> http://blog.iamexec.com/post/27985240814/get-exec-to-volunteer-for-charity-on-your-behalf

<comment><USER2> Thought question: is it better to pay $50 for 2 hours of volunteer time to a charity or just donate that $50 to the charity?

I honestly don't know the answer, but would love to hear what other people think.

My quick take is that it's probably better to give the $50 to the charity because they are better prepared to make a decision on how it should be used. With that being said, I can see how a lot more people might be willing to pay Exec for volunteer hours because of the _feel good_ factor.

Regardless, I think it's an great initiative.

<comment><USER3> Give $50 to the charity. If they prefer 2 hours of volunteer time to $50, then they can go out and buy that.

Call options have value.

<comment><USER4> Buy volunteer time?

<comment><USER2> i.e. hire people to work for the charity—probably at a significantly cheaper rate than $25/hour.

</comment></comment></comment></comment><comment><USER5> This is so stupid I don't know what to say.

If you believe in the charity then give them the money directly.They can find much more efficient and creative uses for it.

If you don't believe in the charity then don't give them the money and don't give exec to give money to give to the charity.

This is a gimmicky stupid idea that is just preying on your guilt.

</comment><comment><USER6> This is _awesome_. We (Weebly) give out a $50 Exec credit every month to all of our employees to help with random life tasks. It's widely used and appreciated.

Some of our employees, though, are further out from SF, and it can be harder to use that credit. The second they got the email this morning, they found a great way to use the credits!

</comment><comment><USER7> "We'll be supporting this program for the next month (now through the end of August), and we'll be donating 100% of all proceeds raised."

I'm confused, do the proceeds go to the charities or to pay the temps? If the former, are the temps just volunteering? If the latter, what do you mean "we'll be donating 100% of all proceeds raised?" Does my $50 yield 2hrs of work _and_ $50 to a charity? Because that would be a great deal!

</comment><comment><USER8> FYI: Exec appears to be invite-only right now, but if you sign up via the "give to charity page" you can get an account.

</comment><comment><USER9> Getting someone else to do your "charity" work for you is not charity...They're not volunteers b/c they're getting paid (by you) to do the work. You're not volunteering b/c you're not doing anything (and you're not even treated as making a donation which would be deductible for tax purposes).

If you are going to use Exec to "volunteer" for you, you might as well just give the money directly to the charity. They can use it on their charitable activities without wasting any time training your Exec "volunteers".

<comment><USER10> Manpower is a priceless commodity for a lot of charities. I know plenty of people who run charities who would pass on a $100 donation in exchange for two hours of idle hands.

<comment><USER11> If that's what they want, then let them use the money to hire an Exec. If not, don't force it on them.

This just limits the charities options, and only benefits exec.

<comment><USER12> Is it possible that after various administrative costs, they don't end up getting $100 worth of labor out of someone, vs. $100 worth of labor by hiring Exec?

<comment><USER9> Exec also takes administrative costs out of that $100. Either way, the charity will have to train the person. But the person the charities hires is likely to come back, so that time is not wasted. The Exec worker may never come back, rendering all of the time spent training them wasted.

</comment></comment></comment></comment></comment><comment><USER13> Ridiculous

</comment><comment><USER14> Brilliant idea!

</comment><comment><USER15> Brilliant! I'm sure this concept will really appeal to all the overworked but socially conscious professionals out there.</comment>


Why We Haven't Built A Better Black Box - <AUTHOR> http://www.popsci.com/article/technology/why-we-havent-built-better-black-box?dom=PSC&loc=poprail&lnk=10&con=why-we-havent-built-a-better-black-box

<comment><USER2> This whole scenario can be avoided. Instead, a constant contact system over low bandwidth satellite should permanently archive plane vital stats to multiple geographically-diverse datacenters to remove the absolutely unnecessary and antiquated dependency on losing a physical "single source of truth." The blackbox is as obsolete as a library card file system, but should be kept as a secondary system.

<comment><AUTHOR> As i understood, the main issue here is cost .. providing satellite links to each and every plane flying out there and to datacenters will be expensive.</comment></comment>


Using Arrows for Dependency Handling - <AUTHOR> http://jaspervdj.be/posts/2010-03-26-arrows-dependencies.html

<comment><USER2> If anyone can explain to me why monads are insufficient, that would be swell. I'm really not going to get it on my own any time soon.

<comment><USER3> Author of the article here. I'll try to give a quick informal explanation. If you look at the type signature of `>>=`:

      m a -> (a -> m b) -> m b

Let's suppose there's a HakyllAction monad. The >>= signature would be:

      HakyllAction a -> (a -> HakyllAction b) -> HakyllAction b

If we implement this operator, we get a value `HakyllAction a` and a function `a -> HakyllAction b`. We can look at the dependencies of the value, but we don't have access to the dependencies of the `a -> HakyllAction b`. If we want that, we need to apply it to the first value.

This goes against the idea of dependency handling -- we want to know the dependencies first, and then only execute the function if needed.

Hope this helps.

<comment><USER2> This helps very much, thanks! :)</comment></comment></comment>


TTY: Ruby gem for building command line apps - <AUTHOR> http://peter-murach.github.io/tty/

<comment><USER2> The question-and-answer system seems similar to node's inquirer module:

[https://github.com/SBoudrias/Inquirer.js](https://github.com/SBoudrias/Inquirer.js)

There's a re-implementation of that same idea for python:

[https://github.com/magmax/python-inquirer](https://github.com/magmax/python- inquirer)

I've been building something recently that uses python-inquirer, although it isn't a perfect fit for my use-case. I'd be interested to know if there are any more similar libraries for python.

<comment><AUTHOR> Thanks for the links, I will take a look. The future goal, idea is to create separate repositories dealing with specifics of command line apps. So for instance, in future I'd extract the prompt inquirer to be a separate gem called 'tty-inquirer' or similar.

</comment></comment><comment><USER3> Looks nice! I have been thinking of extracting some code into a gem like this; now I might not have to.

Features I need, though:

\- Creating tables where you know the desired column widths (number of characters or percentages) but you don't know the number of rows yet, because you'd like to stream the rows, not wait for all the data until rendering.

\- Display progress on a single line and the ability to clean the current line when done. Typically this is stuff like percentage/bytes completed. Spinner would be nice.

\- Display an incremental series of steps that get a checkmark and turn green when ok, or display an error symbol and turn red when not.

Will see if I have time to work this into your gem.

Your site is a little broken, by the way. The API link doesn't go to any API documentation, and on the Usage page, only the table links in the sidebar work.

<comment><AUTHOR> Thanks for you comment! Your feature requests are definitely where I want the library to go so I went and added them to tracker [https://github.com/peter- murach/tty/issues](https://github.com/peter-murach/tty/issues) as a future reminder. Please feel free to submit more suggestions or PR!

Few people pointed out the broken website to me, I'll definitely fix. I

</comment></comment><comment><USER4> Over the past couple years I've been building little libraries in ruby for a boxing simulator I plan to make some day. I've already built the name generator, region generator, coordinate system for the ring movement, json file db, etc.

The problem I've had is figuring out where I bring this all together, I've debated making it web enabled, standalone app, etc. I think I might just use this library and make it CLI based, the table library makes things really interesting for managing stats and events- I actually have a pretty strong use case for this to all be plugin based. I'd love to have my little sim running in a terminal window while I'm hacking on my web projects.

Anyway, very cool stuff, I will be investigating much deeper very soon!

<comment><AUTHOR> Sounds interesting! If you come to use the library and have any thoughts or features requirements please post them on the issue tracker.

On another note I suppose, the choice of the interface for a boxing simulator to be cli client is really good for prototyping and is sweet for terminal power users.

</comment></comment><comment><USER5> There's stuff in TTY that does not belong in core (table rendering, logging), and there is a great lack of features that is available by default in [MooseX- App]([http://p3rl.org/MooseX::App](http://p3rl.org/MooseX::App)): bash completion, typo detection/suggestions, command words (à la `git foo`, `svn foo`).

TTY's choice of eliminating dependencies is short-sighted. By embracing dependencies, a library can be more powerful, have more features, solve more problems.

<comment><AUTHOR> I've started TTY library as an extraction from another project. It was born out of necessity to keep things that are generic in another place. Even more so, a lot of TTY library is devoted to supporting table rendering, surprising or not it involves terminal properties detection, ansi strings handling etc...

Thank you for pointing me to Perl library. The only thing I would say is that TTY gem does not have option parser and will probably not have one. Its main concern is more focused on prompting for values than actually providing a way to structure command line interface. There are already libraries that do an excellent job of that. Other features I will have to look individually into. I'd love to have more input on that from yourself.

I have actually recently thought about the dependencies for this library. Originally I wanted to make it easy to vendor things but I have actually started extracting code from this lib as well. For example, the [https://github.com/peter-murach/equatable](https://github.com/peter- murach/equatable) library. So I definitely agree with you and think this is the direction I'm gonna go!

</comment></comment><comment><USER6> Looks great, I will probably use this to make scripts at work.

Note: the side-nav on the Usage page ([http://peter- murach.github.io/tty/usage/](http://peter-murach.github.io/tty/usage/)) doesn't work for me. I can only get to Table Creation.

<comment><AUTHOR> Sorry, I didn't have time to finish the usage page but the following readme should be comprehensive [https://github.com/peter- murach/tty](https://github.com/peter-murach/tty)

</comment></comment><comment><USER7> ANSI gem does a lot of this already [http://rubyworks.github.com/ansi](http://rubyworks.github.com/ansi). I'm always a bit leery of all-in-one libraries. If libraries have good SOC then it's nice to be able to mix and match.

<comment><AUTHOR> I agree, all-in-one proposition is not my style either. From what I can tell the ANSI gem deals only with ansi strings transformations. This library has ansi string coloring but only to support output colorization for the shell.

The tty gem has a rather specific scope, which is to help read data in from command line and display it in some pleasant form such as data table to the user. This library does not deal with parsing command line arguments. There area already awesome propositions out there such as [https://github.com/erikhuda/thor](https://github.com/erikhuda/thor) or [https://github.com/leejarvis/slop](https://github.com/leejarvis/slop) to name a few. Basically tty gem tries to fit in the middle ground between gems that are options parsers and complete solutions for structuring command line apps. It is a sort of glue for common tasks based on my experience writing command line apps.

<comment><AUTHOR> In future I will break dependencies out into smaller components such as tty- prompt tty-table tty-terminal etc... which should help in mixing and matching what you need and the tty gem itself may be just a meta gem that pulls them all in.

</comment></comment></comment><comment><USER8> Right on! This is a project I'll be keeping an eye on!

<comment><AUTHOR> If you find any issues, or have suggestions then please write up on the [https://github.com/peter-murach/tty/issues](https://github.com/peter- murach/tty/issues) tracker.</comment></comment>


Moving a large and old codebase to Python3 - <AUTHOR> https://medium.com/@boxed/moving-a-large-and-old-codebase-to-python3-33a5a13f8c99 <comment><USER2> Many of your observations feel like lurking bugs in your py2 which only exposed because you moved to py3. Others felt like the kind of design decision you regret irrespective of language binding, like depending on an externally sourced component from a company with bad customer engagement.

I still struggle with u'string' and use of encode() and decode() in the presence of input streams from the web which don't identify encoding, are probably Microsoft isolatin1 and get uplifted into UTF-8

I believe your code would benefit from py3 typing but have no personal experience of it: I just observe many of your problems felt like weak type binding problems across boundaries.</comment>


Magnus Effect – KFC Paper Bucket Airplane - <AUTHOR> https://www.youtube.com/watch?v=K6geOms33Dk <comment><USER2> This one actually works: [https://youtu.be/gjMbfxsHXw4](https://youtu.be/gjMbfxsHXw4)

and as a bonus another contraption using a different principle: [https://youtu.be/CiU71GFs4Fs?t=178](https://youtu.be/CiU71GFs4Fs?t=178)</comment>


Angular: A Radically Different Way of Building AJAX Apps - <AUTHOR> http://www.youtube.com/watch?v=elvcgVSynRg

<comment><USER2> <http://www.youtube.com/watch?v=0iQCLlu1dko> for a higher resolution in which you can read the code.</comment>


Youtube for high quality video (plug-in install required) - <AUTHOR> http://stage6.divx.com/

<comment><AUTHOR> Also see <http://www.joox.net> which is an index of particularly good videos from Stage6.</comment>


Phones can now tell who is carrying them from their users' gaits - <AUTHOR> https://www.economist.com/science-and-technology/2019/05/23/online-identification-is-getting-more-and-more-intrusive <comment><USER2> > Using these variables, UnifyID sorts gaits into about 50,000 distinct types. > When coupled with information about a user's finger pressure and speed on > the touchscreen, _as well as a device's regular places of use_ —as revealed > by its GPS unit—that user's identity can be pretty well determined

And the devil is in the details. While gait detection will improve and become a huge security issue in the near future, for now we can already usually identify someone by their GPS history.

The need for such data, and the intentional ambiguity over which bit of data is actually the most useful, tells me this tech isn't where it needs to be yet and this article is a bunch of hype.</comment>


'Never-before-seen material' can store vast amounts of energy - <AUTHOR> http://www.gizmag.com/high-pressure-energy-storage-material/15614/ <comment><USER2> Releasing the energy under control isn't discussed - I'd like to know if it's possible, and how they'd do it.

<comment><USER3> It's a spring. You put in mechanical energy, you get back mechanical energy and heat. The engineering challenge, I think, is making something that can compress a useful quantity of the stuff.

<comment><USER4> > The engineering challenge, I think, is making something that can compress a > useful quantity of the stuff.

That's spot on.

To me the whole concept sounds like a mechanical ratchet and a spring, the pressure pushes the chemicals in to a configuration they would not normally achieve because of repulsive forces, the pressure helps to overcome those forces and then the new dominant force locks in the configuration so the pressure can be removed.

After that if you weaken the force that holds everything together the molecule expands to its original size and will release a bunch of energy as heat in the process.

<comment><USER3> I don't think the pressure _can_ be removed. Nothing in the article says this "material" is stable at ordinary pressures. They're just saying that the chemical structure changes as it is squeezed into a smaller and smaller space. If you let go, it presumably expands immediately.

To be clear, I also think the energies they are storing in their experiment are a small fraction of a joule. The "energy density" is high because the sample is very small.

<comment><USER4> If that's the case then any speculation as to applying this material is completely premature.

<comment><USER5> It is the case. It's not a ratchet and a spring, it's just a spring which can be compressed further than any spring before. (The phase changes along the way are interesting, but will reverse themselves as you release the pressure).

Now, if you could get a giant diamond anvil cell (with house-sized near- flawless diamonds), you could use it to compress a macroscopic quantity of this down, and then get the energy back. The problem is that while the substance in its compressed form may have more energy per cubic foot than, say, a tank of gasoline, in releasing that energy it would expand to something much larger, so your entire apparatus would be _very_ space-inefficient for energy storage (not to mention the difficulties of obtaining those giant diamonds).

<comment><USER4> Ok. I got taken in by the 'energy stored in chemical bonds' bit.

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> Obviously weak on details but it would be pretty interesting to think that energy stored in crystals (as so many sci-fi worlds use) is actually a reality.

On the topic of details, any ballpark conceptual idea on how efficient it would be storing and retrieving the energy from a source like this?

<comment><USER4> Creating such pressures requires very tricky engineering in order to do it on a scale that you can actually use so I would wager that it would not be very efficient.

Diamond anvils are not exactly high volume devices. There may be a way around that but we don't currently have one that I'm aware of.

</comment></comment><comment><USER7> Pressurizing energy into more dense forms of enegy? Goodness, they've gone and invented energon cubes!

</comment><comment><USER8> This material sounds oddly familiar...

[http://en.wikipedia.org/wiki/Red_mercury#Red_Mercury_as_a_ba...](http://en.wikipedia.org/wiki/Red_mercury#Red_Mercury_as_a_ballotechnic)</comment>


Scientists 'may have crossed ethical line' in growing human brains - <AUTHOR> https://www.theguardian.com/science/2019/oct/21/scientists-may-have-crossed-ethical-line-in-growing-human-brains <comment><USER2> Bioethics is in this case exceedingly silly. There is a necessity to cross the line here as you may not go forward with understanding without growing that spontaneous complex system. This is not to disregard concerns but you really have to play with these systems to understand consciousness even. The future bulk of sentiences of all kinds may benefit from the new experimental paradigm here. Reactionary bioethics is as detrimental to progress as its antithesis in bad ethics.</comment>


Brandon Allgood - First Day With Google Glass - <AUTHOR> https://plus.google.com/102178182849845958879/posts/RkNZhBArLmF <comment><AUTHOR> quote: "Finally, there are two things that I would change. First, you can't frame the photo before it shoots. When you say "ok glass, take a picture," it just takes a picture without a delay. The camera obviously has very different optics than your eye so I found myself taking about three photos to get the one I wanted. "</comment>