How to Host Your Own Private Git Repositories - <AUTHOR> https://eklitzke.org/how-to-how-your-own-private-git-repositories <comment><USER2> For those who aren't aware, Git is actually a fully decentralised system. It doesn't _require_ a central server as such - though most teams use one, as it's a convenient setup for most projects.

Even if you are hosting on github/bitbucket/et. al. though, that repository is just one of many equals. You can push and pull from multiple peers as long as you have access set up appropriately.

I recommend the chapter on distributed workflows in Pro Git:

[https://git-scm.com/book/en/v2/Distributed-Git-Distributed-W...](https://git- scm.com/book/en/v2/Distributed-Git-Distributed-Workflows)

There's also an explanation of the different supported protocols here:

[https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protoco...](https://git- scm.com/book/en/v2/Git-on-the-Server-The-Protocols)

<comment><USER3> > Even if you are hosting on github/bitbucket/et. al.

Normally if you're hosting on one of those sites, you're using other features (wiki/issues), which may _not_ be decentralised

</comment></comment><comment><USER4> Gitlab also can be run in your own server. It actually has an enterprise and an open source version. We use the open source one for a couple of years and it is really great - I recommend it with all my heart.

It has great instructions for installing directly from source and you don't really need to be familiar with ruby to install it. It requires some standard components (web server, database) which should exist on all servers and then you follow the instructions and presto! You have your own gitlab!! It also has great upgrade instructions so you can always be up-to-date.

I know gitlab can also be used through the cloud version (and it even has free private repos) however some organizations feel better if the source code of their projects stay inside the organization.

<comment><USER5> Gitlab is massive though. I think it's a great solution for teams on dedicated hardware, but if you need something quick, low-maintenance and lightweight Gitlab might be a bit overkill.

<comment><USER6> You can't get much quicker or low maintenance than gitlab, though it is definitely not lightweight.

<comment><USER7> Gogs? Gitolite?

<comment><USER8> Or just plain git, as in TFA.

</comment></comment></comment></comment></comment><comment><USER9> This is a good setup if you are the only one accessing the repo.

If you need something a little bit more complex, I would highly recommend gitolite for managing repositories & users. Configuration is done via some INI/TOML-like files in a git repo. User public keys are stored in the same repo.

<comment><USER10> What about Gitlab? Isn't that more popular than gitolite?

<comment><USER9> My impression is that GitLab is a web application. It does not really serve the same use case. Web access is good for open source projects where people may want to read the source without downloading the full repo. In the case of private projects, chances are that everyone involved will want to clone the whole repo anyways.

<comment><USER11> I don't mean to be pedantic, but Gitlab helps to host your own private git repos, which fits the title of the article. The article goes further, giving an example of how you can do some bare metal git hosting on a lightweight VM.

It's the same as running postfix/dovecot for configuring your own mail server (which could run on a lightweight VM), or using a turnkey solution such as Zimbra (which will include spam/virus filters, LDAP, calendars and much more).

Depends on your organisation: how often do you create accounts? who can do the sysadmin work? etc. I'm happy to sit back and let managers handle account management, and to be able to put Gitlab/Zimbra on a job description if we need to hire someone.

</comment></comment></comment></comment><comment><USER12> I've been using Gogs happily for two years:

[https://gogs.io/docs/installation](https://gogs.io/docs/installation)

<comment><USER13> Eh. The method described in this post (ie bare repositories on a filesystem and ssh transport) is perfectly sufficient for my personal use if I'm hosting. The minute there's a MySQL dependency I'm a hard pass...

I buy the need for the gitlabs of the world when multiple users show up, if only because managing credentials is a pain. But for single user use cases I wouldn't waste my time.

<comment><USER14> The instructions say that you can just use SQLite, though.

"Based on your choice, install one of supported databases or _skip this step_ "

</comment></comment></comment><comment><USER15> Assuming you already have files in your home directory on the server backed up, and SSH access, then a repository for a single user is as simple as

      mkdir project.git; cd project.git
      git init --bare

And to clone

      git clone firstname.lastname@example.com:project.git

</comment><comment><USER16> "Doing this is cheaper than paying GitHub, and it will give you the satisfaction of being a True Hacker."

Or I could work on problems that really matter and leave the sysadmin job to someone who gets paid to do it. ;)

More seriously, when I was in college, I spent a lot of time doing things like running my own mailserver, selfhosting various projects, etc. I learned a lot. But in the Real World, I don't want to be responsible for more than I have to be; off the shelf products are just better for me, most of the time.

The fact that Bitbucket and Github will pay a guy to run a git server for me is amazing (even if it is evidence of some sort of irrational enthusiasm on part of VC firms). Why would I not want to take advantage?

<comment><USER17> Except running a git server is little more than having a place to store a git repo and giving ssh access to it. There's really no maintenance if you already have the server. What github et al provide isn't repo hosting so much as fancy UI tools on top of that.

Edit: seriously, I wonder how many people who just automatically go to github have ever bothered to try the simple act of creating a git remote on a file server on their own network, or even just to a different host. It's really easy, and it really underscores how _simple_ it is to have your repo distributed without any 3rd party infrastructure. Once you see that, you see that putting a copy on a shell account on your hosted VM is dirt simple and requires almost no administrative burden.

<comment><USER18> On the contrary, there's a ton of maintenance, and the hosting providers like GitHub and Microsoft pay teams of people to deal with the infrastructure. (I've worked on both.) This involves not just the physical infrastructure like the servers, though of course there's that, but also maintaining the bits on disk. Your repository will get duplicated across multiple disks on multiple machines, perhaps in different availability zones, and then of course they're backed up to yet another location.

So what companies like GitHub and Microsoft provide is - yes - the fancy tools on top but also teams of professionals ensuring that your repositories are available quickly.

<comment><USER19> GitHub etc. need "a ton of maintenance" because of the "fancy tools", which are an unusually complex and sophisticated constantly evolving web application with many users.

A private source repository is far less demanding: it's almost never upgraded, and for system administrators it's just another server to keep running and another file system to back up.

<comment><USER18> I'm not talking about the fancy tools. I'm talking about just serving Git repositories, not about web applications.

GitHub is distributing your Git repository across multiple servers in multiple racks in real time for reliability and availability and is the world's largest Git repository hosting provider. Some nice conference talks discuss this, like from Git Merge: [https://www.youtube.com/watch?v=f7ecUqHxD7o](https://www.youtube.com/watch?v=f7ecUqHxD7o) and GitHub Universe: [https://www.youtube.com/watch?v=DY0yNRNkYb0](https://www.youtube.com/watch?v=DY0yNRNkYb0)

Visual Studio Team Services is hosting your Git repository across Azure, and is hosting the world's largest Git repositories. [https://arstechnica.co.uk/information- technology/2017/02/mic...](https://arstechnica.co.uk/information- technology/2017/02/microsoft-hosts-the-windows-source-in-a-monstrous-300gb- git-repository/)

I have my own Git server as well, and I agree that its maintenance isn't very demanding. But I'm not putting production bits on it. My open source repositories go to GitHub and my private repositories go to VSTS - they're providing a level of service that I simply can't match by myself.

<comment><USER17> I'm not talking about putting production bits on my own git server, either. I'm talking about how easy it is to create a couple of personal remotes just as a second and third copy of whatever I happen to be working on on my laptop. One goes to my NAS and one goes to my rackspace VM that I keep around for random projects.

I have github and bitbucket accounts, but for little projects, I much prefer the simplicity of effectively just having dupes of my repos on other machines of mine. And it's really nice that the way I interact with them is precisely the way I'd interact with github or repositories at work, despite the fact that they're just directories sitting behind an ssh connection.

</comment></comment></comment></comment></comment></comment><comment><USER20> Why do this when [http://bitbucket.com](http://bitbucket.com) will host private git repos for free? They also have have Large File Storage implemented as well.

I use GitHib client using BitBucket for repo hosting with LFS and it works great, no need to host anything.

<comment><USER21> > _Why do this when[http://bitbucket.com](http://bitbucket.com) will host > private git repos for free?_

Because you never know when one of these online services will suffer an outage, suffer a security breach that leasks your private repos or email & credentials, or even lose your data entirely. The fact that the service is free doesn't mean that it doesn't come without potential issues.

<comment><USER22> But... you are using another online service to host the service yourself, no? And presumably they are also throwing in backups and redundancy of some sort... certainly it would take you a minute to set those things up, test them, monitor they are working... And isn't GitHub basically like everyone's resume these days?

I don't know... at some point you sort of just have to trust someone... be it the hosting provider, or the service provider. And I'm old... but I've had to untangle issues with CVS / VSS / SVN / etc... over the years I don't want anything to do with that crap -- if I can punt it to someone else to manage I'm OK paying some tiny subscription fee.

I think there's been one day in the last ~10 years when I couldn't use GitHub. To me that seems worth the $20 a month, or whatever they charge now.

<comment><USER23> It's especially sad because git is distributed and every time there's a GitHub outage I hear online some teams are blocked for the day. But everyone has the whole repo. You're not screwed like if your SVN or Perforce server goes down. Anyone could become the new "remote to push to / pull from" until the outage is resolved, or you could set up one of these bare repos somewhere pretty quick. When the outage is resolved someone just pushes to the original and you're all fine.

<comment><USER24> This is what happens when people cargo-cult git because it's what the cool kids are doing, instead of actually making an informed choice.

<comment><USER25> S/git/GitHub/

Fixed that for you.

<comment><USER24> Well, that too, but the issue here (thinking that a central repo being offline means you can't use your decentralized version control system) shows that they don't understand git in any form.

<comment><USER25> I think it's honestly that some people think Git === GitHub, or that GitHub has some magic secret sauce that makes things work.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER26> If you don't need code review and don't mind a hosted solution, you can get by with the AWS free tier and use IAM for all your access control.

        AWS CodeCommit:
        5 active users per month
        50 GB-month of storage per month
        10,000 Git requests per month
        Does not expire at the end of your 12 month AWS Free Tier term.

[https://aws.amazon.com/s/dm/optimization/server-side- test/fr...](https://aws.amazon.com/s/dm/optimization/server-side-test/free- tier/free_np/)

</comment><comment><USER27> Very interesting benchmark of gitbucket vs gitea vs gitlab on a raspberry pi ;)

[https://gitbucket.github.io/gitbucket- news/gitbucket/2017/03...](https://gitbucket.github.io/gitbucket- news/gitbucket/2017/03/29/benchmark-of-gitbucket.html)

</comment><comment><USER28> Security question. Can `git-shell` restrict users to their remote home directory? Or if you give me a git shell, can I still do things like `git clone email@example.com:/home/you/secret-sauce` ?

This is only an issue if you're sharing the box and/or remote repositories with other people. For shared remote repositories I've been using the following setup:

1\. Create a bare, shared repository at `/var/git/foo`. Configure unix group permissions and the directory setuid bit on it.

2\. Give alice access via a `/home/alice/foo -> /var/git/foo` symlink.

3\. Set alice's shell to a patched version of the git shell I call `git-home- shell` that sanitizes the repository path argument and makes it relative to her home dir.

Is there a better way these days?

<comment><USER15> Why not just set standard file permissions (owner and group)?

You could create a group for each repository, and add and remove members as necessary.

<comment><USER28> This is precisely what I do.

But, I'd prefer it if git-shell didn't let users probe and read git repositories at any absolute path on the remote end. That's not great behavior for a restricted shell.

<comment><USER25> Remove the 'others' read/execute permission from user home directories.

<comment><USER28> Sure, but there might be git repos sitting around elsewhere. Why risk exposing a git repo literally anywhere in the filesystem to a restricted shell account?

<comment><USER25> Then use a chroot.

<comment><USER28> You could do that, but that means for a shared repo and N git shell accounts you've got N chroots, presumably using null or bind mounts.

That's a lot more work than a restricted shell which just...restricts.

<comment><USER25> True, it all depends what your requirements are.

Personally I'd just designate a path for shared repos (e.g. /srv/vcs/<project>{.git,.hg} etc), give people write access using ACLs and group membership. If they create repos in their home directories, thats their business.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER29> Quick note: what this article doesn't explicitly says is that as long as you have a shell account somewhere with a decent amount of disk space, you can host or mirror all the repository you want.

If I may make a suggestion, I'd recommend the Super Dimensional Fortress Public Access UNIX System ([https://sdf.org/](https://sdf.org/)).

They're NetBSD-based if I remember correctly, and for a low fee (36$/lifetime ARPA membership + 9$/quarter) you can host most of the things you would like to host.

And you don't have to do system maintenance.

<comment><USER30> I thought the ARPA membership was yearly?

</comment></comment><comment><USER31> Why self-host your repo but store backups without encryption at google or amazon? If you want it to be private, just make it so.

edit: thanks anyway for your version!

<comment><USER32> Privacy isn't binary, and there's a large difference between "Amazon could _potentially_ read this, but they'd be breaking their own ToS and some laws to do so" and "Public on the internet".

<comment><USER31> But what is the difference with BitBucket then?

Besides, if you worry that state actors are interested in your source code, I do not see how Amazon being law-abiding would be of any help here..

</comment></comment></comment><comment><USER33> I do self-host a few repositories as well, but I do not set up a separate user: I just create a git/ dir in the home dir of the account I want to host the repositories on and put the repositories there.

To simplify the initial setup, I created a handy shell script, reposetup [1]. It makes to create repositories, push to them and remind me their urls.

[1]: [https://github.com/agateau/reposetup](https://github.com/agateau/reposetup)

</comment><comment><USER34> If you're using Google Cloud, you can already use Google Cloud Source Repositories. [https://cloud.google.com/source- repositories/](https://cloud.google.com/source-repositories/) It supports git and the Beta release of Cloud Source Repositories provides free hosting of up to 1GB of storage.

<comment><USER35> Yup and it can mirror Bitbucket which is also free. So you can just create it in Bitbucket and get free backups via Google.

</comment></comment><comment><USER36> As others have already stated, this article is a great introduction for when you'll be the only one to access the repositories, as anyone able to authenticate for that account will have access to all repos.

There are some tools that restrict access with varying levels of granularity, but if you just want to restrict access on a per-repo-per-sshkey basis, one of my projects is a simple shell script that does just that:

[https://github.com/cbdevnet/fugit](https://github.com/cbdevnet/fugit)

It originally came to be because I've found gitolite too big to maintain for simply sharing some repositories with a few other people. It has since served me well and is used in some business applications, too.

</comment><comment><USER37> Does anyone know of a good AMI or Docker container that's got all this already set up, as far as it's possible?

(I know it doesn't look complicated, but if there's a decent "standard" already out there...)

<comment><USER38> Gitlab has their own docker images, and it includes pretty much anything you could ever want out of a git service.

[https://hub.docker.com/r/gitlab/gitlab- ce/](https://hub.docker.com/r/gitlab/gitlab-ce/)

</comment></comment><comment><USER39> [http://gitblit.com/](http://gitblit.com/) is also worth looking into. It is more sophisticated then gitolite (which I also use) and less hairy then gitlab. It is Java based, but doesn't require a database.

Also, for backup, rather then tar up the ".git" directory, I use "git bundle <backupfilename> \--all" which creates a flat file with all branches included. This file can then be uploaded to GCS or S3.

</comment><comment><USER40> If you want something light weight and "run and done" then check out GitBucket [0]. You only need the JVM & git installed. When you run the program it sets everything up. Very easy, clean interface, and simple to back up (I just snapshot the entier folder).

[0] - [https://github.com/gitbucket/gitbucket](https://github.com/gitbucket/gitbucket)

</comment><comment><USER41> Just do it in google drive or dropbox, get backups for free.

[https://stackoverflow.com/questions/1960799/using-git-and- dr...](https://stackoverflow.com/questions/1960799/using-git-and-dropbox- together-effectively/1961515#1961515)

</comment><comment><USER42> Has anyone had any experience in getting Passbolt ([https://github.com/passbolt](https://github.com/passbolt)) working for authentication with Git?

</comment><comment><USER43> I do this often. One thing, if you want to have multiple users all working on the same repo, which I believe is a common use case, you have to take group permissions and umask into account. Works really nice.

</comment><comment><USER44> Kallithea is good enough for this use case. We are using it in a 15 member team, without any issue.

</comment><comment><USER45> Anyone use AWS's CodeCommit as a mirror for your GitHub repository?

</comment><comment><USER46> What this article doesn't cover are how to set up the things that make Github so useful like issue tracking and pull requests. Github (and similar services like bitbucket) are more than just Git.

</comment><comment><USER47> pip install git-remote-dropbox

Is a git extension to allow a Dropbox to be used as your remote. Works from the CLI. Been using it for two years.

</comment><comment><USER48> Mmm. Just use GitLab/Gogs on cloudron?

</comment><comment><USER49> I use Gogs and a self-hosted sandstorm.io.

<comment><USER50> The gogs package is ancient. I woukd be very careful of running outdated stuff much less recommending it to others

</comment></comment><comment><USER51> RhodeCode is a good option for hosting, it has an advanced permission system, streaming push support and it scales well.

<comment><USER52> Thanks for the pointer. Your service looks interesting!

A little advice: it's probably best to post a disclaimer that you are the founder of RhodeCode whenever you post about it on HN. OTOH, you get credit for including that info in your HN profile.</comment></comment>


Show HN: ExDOS 64-bit version source code release - <AUTHOR> Hi! I'm just posting to announce the release of the source code of the 64-bit version of my hobby OS, ExDOS. My site is here: http://exdos.co.nf/ and my source code is on GitHub: https://github.com/omarrx024/exdos64 It's licensed under GNU GPL v3 and has many improvements over it's old 32-bit version. This one has a truly functional ACPI driver on real hardware, a window-based GUI, a real disk driver independent of BIOS, and some other things. <comment><USER2> Looks really cool.

One thing, though:

> tiny

> RAM: 64 MB required, 192 MB recommended.

That doesn't seem particularly tiny to me. I have an old Pentium II box with 32 MB of RAM that runs the latest release of OpenBSD with X, and I don't consider OpenBSD particularly tiny, either.

At risk of sounding like a crotchety old man, these are sad times to be living in when 64 MB is considered tiny.

<comment><USER3> Classic DOS barely took up _kilobytes_ of memory. I think that qualifies as "tiny". Megabytes is downright bloated by comparison.

Considering this is written in assembly, what is all that memory used for?

<comment><USER4> Well, for one thing, it's a graphical OS.

<comment><USER2> What does that have to do with anything? Windows 3.1 had a minimum RAM requirement of 1 MB. The base model of the Apple Lisa 2, which featured a graphical OS, had 512 KB of RAM. It's possible to have graphics without requiring so much RAM.

</comment></comment></comment></comment><comment><USER5> This is amazing, good work!

Can I ask what references you used to figure out how to write certain pieces of this? There is a torrent of information online, but you've probably got a very good (curated) set of links or books that you recommend.

<comment><AUTHOR> Well, I've never read a real book about OS development. But I can recommend the OSDev Wiki and Forum, and of course the specifications of everything you need. I've used Intel's Development Manual Volume 3 as reference, as well as ACPI's specification, and some others.

</comment></comment><comment><USER6> [https://github.com/omarrx024/exdos64](https://github.com/omarrx024/exdos64)

Maybe someone could change this to a Show HN?

<comment><USER7> Sure, we've added that to the title.

</comment></comment><comment><USER8> Related: [https://news.ycombinator.com/item?id=10045254](https://news.ycombinator.com/item?id=10045254)

<comment><AUTHOR> That OS is also developed by me, but it was 32-bit and had design issues. So I redesigned it and rewrote it in 64-bit and here it is.

<comment><USER8> Thanks, That was my guess. I posted the link to add context and because the progress since is pretty awesome.

</comment></comment></comment><comment><USER9> Very impressive. Maybe it can be used in unikernel with freestanding applications.

Some Suggestion: do not focus on GUI at first, since it will not be usable soon as desktop OS anyway.

I could imagine that a barebone ExDos to manage multiple unikernel ExDOS virtual machines as web services is quite useful.

Any comments?

</comment><comment><USER10> According to about page on his website, the author is "a 14-year old computer hobbyist."

Quite impressive!

</comment><comment><USER11> Very cool!

It (almost) runs on copy.sh V86 emulator: [https://copy.sh/v86/](https://copy.sh/v86/)

I see the boot process with dots (like linux) and after I have the following message with a red background (if that can help):

        ExDOS64 version 0.01 built 26.03.2016
        </comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>=
        Boot error: CPU is not 64-bit capable...

The last lines of the Javascript console:

       [CPU ] mode=real/16 paging=0 vm=0 iopl=0 cpl=0 if=1 cs:eip=0xF000:0x0000FFF0 cs_off=0x000F0000 flgs=0x202 ss:esp=0x0000:0x00000F32 log.js:13:9
       [CPU ] far return eip=0x0000CB01 cs=0xF000 stack_adjust=0x0

<comment><AUTHOR> It clearly says "Boot error: CPU is not 64-bit capable..." which means your CPU is not 64-bit. The V86 emulator doesn't support 64-bit mode and so can't run ExDOS.

</comment></comment><comment><USER12> Is it able to run user-created programs? And if so, with what tools?

<comment><AUTHOR> Not yet, because I am rewriting the multitasking subsystem.

</comment></comment><comment><USER13> Reminds me of MenuetOS.

<comment><USER14> Would be cool to have a tiny OS run in the boot manager.</comment></comment>


Ask HN: Best books/videos on how to be an autodidact? - <AUTHOR> Any books/videos/online articles that you found 'illuminating' on how to become an autodidact? <comment><USER2> Ultimately, IME, no resource will ever tell you how to _practically_ become one but personally I found these resources helpful:

* 'Mastery' by Robert Greene

* Learning How to Learn (on Coursera)

* I find OCW (on YouTube) pretty inspiring

* 'Ultralearning' by Scott H. Young

* Ask lots of questions, keeping asking and then ask some more. You have Google and YouTube so don't worry, you will find an answer... eventually.

\+ I'm naturally a very curious guy and my mind won't just rest until I learn (more about) that thing, whatever it might be.</comment>


"What next?" - <AUTHOR> http://graydon2.dreamwidth.org/253769.html <comment><USER2> Again my pet ignored language/compiler technology issue goes unmentioned: data layout optimizations.

Control flow and computation optimizations have enabled use of higher level abstractions with little or no performance penalty, but at the same time it's almost unheard of to automatically perform (or even facilitate) the data structure transformations that are daily bread and butter for programmers doing performance work. Things like AoS->SoA conversion, compressed object references, shrinking fields based on range analysis, flattening/dernormalizing data that is used together, converting cold struct members to indirect lookups, compiling different versions of the code for different call sites based on input data, etc.

It's baffling considering that everyone agrees memory access and cache footprint are the current primary perf bottlenecks, to the point that experts recommend considering on-die computation is free and counting only memory accesses in first-order performance approximations.

<comment><USER3> I've been thinking about this for the last few years. What would an APL-like language look like with structured data? Is that possible? Could you make a language where you specify if a value is SoA or AoS? Is it possible to automatically convert an AoS-based algorithm to SoA?

It really changes how you do basic things like sorting. In the standard AoS approach in C-like languages you swap entire structures around the array. In an SoA approach in APL-like languages you generate a list of indices that would put the data in sorted order then apply it to each column. A number of times I written code to do this in C++ for high-performance systems, and it works great, but is definitely a different way of thinking about things.

<comment><USER4> _Is it possible to automatically convert an AoS-based algorithm to SoA?_

Does this require anything more than transposing some struct member accesses? IIRC, Futhark already does that kind of conversion.

<comment><USER3> You could do a fairly straightforward conversion but it would be terribly slow for many things.

Take the sorting example i gave. In a column-oriented program you would generate a list of indices and apply them to each column. That has very good cache locality as you work on each independently. Also you tend to manipulate that index list instead of the data and after all is done, filtered, and whatever then apply it to the data.

If you did things the AoS way you would be bouncing around in memory going from column to column.

Dealing with SoA and column orientated data is more than just a storage decision.

<comment><USER4> _You could do a fairly straightforward conversion but it would be terribly slow for many things._

Is there a non-straightforward conversion that isn't? It seems to me like any SoA->AoS transformation is going to have pretty much the same effect on locality.

<comment><USER3> > It seems to me like any SoA-AoS transformation is going to have pretty much > the same effect on locality

Not at all. In a SoA system you want to operate on each attribute individually but on an AoS system you operates across structs. Besides improved cache locality it keeps loops small so they operate out of the iop loop/stream cache among other things like better packing off data etc.

If you haven't worked on a system little this sometimes it can be difficult to see how different things can be. It's literally APL vs C.

</comment></comment></comment></comment></comment></comment><comment><USER5> Grayson's very first answer to "what's next" is "ML modules," a language feature probably few people have experienced first hand. We're talking about ML-style modules here, which are quite precisely defined alongside a language (as opposed to a "module" as more commonly exists in a language, which is just a heap of somewhat related identifiers). ML modules can be found in the mainstream ML family languages (Standard ML, Ocaml) as well as some lesser known languages (1ML, Manticore, RAML, and many more).

It's really hard to do justice explaining how amazing modules are. They capture the essence of abstraction incredibly well, giving you plenty of expressive power (alongside an equally powerful type system). Importantly, they compose; you can write functions from modules to modules!

(This is even more impressive than you think: modules have runtime (dynamic) AND compile time (static) components. You've certainly written functions on runtime values before, and you may have even written functions on static types before. But have you written one function that operates on both a static and a dynamic thing at the same time? And what kind of power does this give you? Basically, creating abstractions is effortless.)

To learn more, I recommend you read Danny Gratzer's "A Crash Course on ML Modules"[1]. It's a good jumping off point. From there, try your hand at learning SML or Ocaml and tinker. ML modules are great!

[1]: [https://jozefg.bitbucket.io/posts/2015-01-08-modules.html](https://jozefg.bitbucket.io/posts/2015-01-08-modules.html)

<comment><USER6> 1ML just shows that advanced (first-class) ML modules are really just System F_omega. That's just barely more than Haskell! More languages need to expose it nicely. But we already have most if not all the technology we need to make them _efficient_ and _worthwhile_ , vs just possible. This isn't a research problem. This is a design/HCI problem.

<comment><USER7> ML modules are great, but I'm not convinced that making them first-class (1ML) will be equally great. ML hits a sweet spot between automation (full type inference) and expressiveness that is only possible because the type language is first-order. This is IMO the point that most extensions on top of Hindley- Milner completely miss.

So, if anything, what I'd like to see is a dependently typed language whose type language is a first-order, computation-free (no non-constructor function application) subset of the value language.

<comment><USER8> The 1ML papers discuss this, ML implementations in reality are already incomplete with regard to Hindley-Milner, a quote:

"We show how Damas/Milner-style type inference can be integrated into such a language; it is incomplete, but only in ways that are already present in existing ML implementations."

</comment></comment></comment></comment><comment><USER9> One big problem we're now backing into is having incompatible paradigms in the same language. Pure callback, like Javascript, is fine. Pure threading with locks is fine. But having async/await and blocking locks in the same program gets painful fast and leads to deadlocks. Especially if both systems don't understand each other's locking. (Go tries to get this right, with unified locking; Python doesn't.)

The same is true of functional programming. Pure functional is fine. Pure imperative is fine. Both in the same language get complicated. (Rust may have overdone it here.)

More elaborate type systems may not be helpful. We've been there in other contexts, with SOAP-type RPC and XML schemas, superseded by the more casual JSON.

Mechanisms for attaching software unit A to software unit B usually involve one being the master defining the interface and the other being the slave written to the interface. If A calls B and A defines the interface, A is a "framework". If B defines the interface, B is a "library" or "API". We don't know how to do this symmetrically, other than by much manually written glue code.

Doing user-defined work at compile time is still not going well. Generics and templates keep growing in complexity. Making templates Turing-complete didn't help.

<comment><USER10> > incompatible paradigms

See _Architectural Mismatch or, Why it 's hard to build systems out of existing parts_[1]

Yes, we are not good at it, but we need to do it. Very often, the dominant paradigm is not appropriate for the application at hand, and often no single paradigm is appropriate for the entire application.

For example, UI programming does not really fit call/return well at all[2].

> attaching software unit A to software unit B .. master/slave

Case in point: this is largely due to the call/return architectural style being so incredibly dominant that we don't even see it as a distinct style, with alternatives. I am calling it 'The Gentle Tyranny of Call/Return'.

[1] [http://www.cs.cmu.edu/afs/cs.cmu.edu/project/able/www/paper_...](http://www.cs.cmu.edu/afs/cs.cmu.edu/project/able/www/paper_abstracts/archmismatch- icse17.html)

[2] [http://dl.ifip.org/db/conf/ehci/ehci2007/Chatty07.pdf](http://dl.ifip.org/db/conf/ehci/ehci2007/Chatty07.pdf)

<comment><USER9> _See Architectural Mismatch or, Why it 's hard to build systems out of existing parts_

If you want to study that, look at ROS, the Robot Operating System. ROS is a piece of middleware for interprocess communication on Linux, plus a huge collection of existing robotics, image processing, and machine learning tools which have been hammered into using that middleware. The dents show. There's so much dependency and version pinning that just installing it without breaking a Ubuntu distribution is tough. It does sort of work, and it's used by many academic projects.

In a more general sense, we don't have a good handle on "big objects". Examples of "big objects" are a spreadsheet embedded in a word processor document or a SSL/TLS system. Big objects have things of their own to do and may have internal threads of their own. We don't even have a good name for these. Microsoft has Object Linking and Embedding and the Common Object Model, which date from the early 1990s and live on in .NET and the newer Windows Runtime. These are usually implemented, somewhat painfully, through the DLL mechanism, shared memory, and through inter-process communication. All this is somewhat alien to the Unix/Linux world, which never really had things like that except as emulations of what Microsoft did.

"Big object" concepts barely exist at the language level. Maybe they should.

</comment></comment></comment><comment><USER11> I'd say the elephant in the room is graduating beyond plaintext (projectional editor, model-based editor).

If you think about it so many of our problems are a direct result of representing software as a bunch of files and folders with plaintext.

Our "fancy" editors and "intellisense" only goes so far.

Language evolution is slowed down because syntax is fragile and parsing is hard.

A "software as data model" approach takes a lot of that away.

You can cut down so much boilerplate and noise because you can have certain behaviours and attributes of the software be hidden from immediate view or condensed down into a colour or an icon.

Plaintext forces you to have a visually distracting element in front of you for every little thing. So as a result you end up with obscure characters and generally noisy code.

If your software is always in a rich data model format your editor can show you different views of it depending on the context.

So how you view your software when you are in "debug mode" could be wildly different from how you view it in "documentation mode" or "development mode".

You can also pull things from arbitrarily places into a single view at will.

Thinking of software as "bunch of files stored in folders" comes with a lot baggage and a lot of assumptions. It inherently biases how you organise things. And it forces you to do things that are not always in your interest. For example you may be "forced" to break things into smaller pieces more than you would like because things get visually too distracting or the file gets too big.

All of that stuff are arbitrary side effects of this ancient view of software that will immediately go away as soon as you treat AND ALWAYS KEEP your software as a rich data model.

Hell all of the problems with parsing text and ambiguity in sytnax and so on will also disappear.

<comment><USER12> This claim is often repeated, but I haven't seen it substantiated even once. It's possible that no one has yet come up with the right answer that "obviously there". But it is also possible that this claim is not true, and a tend to believe the latter more as time passes.

Every attempt that I've seen, e.g. Lamdu, Subtext, any "visual app builder", all fail miserably at delivering ANY benefit except for extremely simple programs -- while at the same time, taking away most of the useful tools we already have like "grep", "diff", etc. Sure, they can be re-implemented in the "rich data model", perhaps even better than their textual ancestors - but the thing is, that they HAVE to be re-implemented, independently for each such "rich data model", or you can't have their functionality at all -- whereas as 1972 "diff" implementation is still useful for 2017 "pony", a language with textual representation.

regarding your example, the "breaking things into smaller pieces" was solved long ago by folding editors (I used one on an IBM mainframe in 1990, I suspect Emacs already had it at the same time, it did for sure in 1996).

the problems with "parsing and ambiguity" are self inflicted, independent of whether the representation is textual. Lisp has no ambiguity, Q (the K syntax sugar) has no ambiguity. Both languages eschew operator precedence, by the way, because THAT is the real issue that underlies modern syntax ambiguities.

I've been waiting for that amazing "software as a data model" approach to show a benefit for almost 30 years now (There's been an attempt nearly every year I looked). Where it has (e.g. Lisp, Forth), it's completely orthogonal to the textual representation.

<comment> iso-8859-1 One advantage I dream of with Lamdu is snapshotting application state and having values annotated in the boxes next to their definition. You could edit the code in the snapshot and see how it propagates through pure parts of the program. It if works, you'd apply the change to the running system.

How do you do this with a text driven program? Typically, there are so many files and unspecified build systems, so you can't view your program as a proper tree as in Lamdu. You can't even treat compilation as a pure function. You can't take a snapshot of an arbitrary program because effects are not isolated. You might not even be able to set breakpoints without breaking the program. If it's machine code you might not even have debug symbols. It's such a mess, and it's different on every platform.

So you claim there is no benefit to be had. I claim the existing solutions are already failing. If one solution gets enough of these things right, there is no reason why it wouldn't succeed just because text-driven. (But it is also possible to do it correctly with text)

If the program code is always to be consistent, it _cannot_ be text, because text allows you to input invalid programs. So how is text not a leaky abstraction?

<comment><USER12> > How do you do this with a text driven program?

If you haven't watched [https://vimeo.com/36579366](https://vimeo.com/36579366) , I highly recommend it. Chris Granger, after watching this, created [http://www.chris- granger.com/2012/02/26/connecting-to-your-c...](http://www.chris- granger.com/2012/02/26/connecting-to-your-creation/) which you can download, and applies to ClojureScript, which is (tada!) text based.

Also, I had a chance to use time traveling virtual machine (which works independently of how your code was produced) in 2007, and while I haven't had a chance to use them, I know that source-aware time traveling debuggers have made huge strides recently.

> So you claim there is no benefit to be had. I claim the existing solutions > are already failing.

These claims are not contradictory. I agree that existing solutions are failing in various ways, but I still disagree that the "code as rich data" would provide benefit.

> If one solution gets enough of these things right, there is no reason why it > wouldn't succeed just because text-driven. (But it is also possible to do it > correctly with text)

So, if possible to do correctly when text driven, why is text driven a problem?

> If the program code is always to be consistent, it cannot be text, because > text allows you to input invalid programs. So how is text not a leaky > abstraction?

All programming abstractions are leaky in one way or another, and text is no different. In my opinion, the leak that it is possible, during design time, to have an invalid program (which will be rejected as such prior to execution) is not a real problem. The requirement that "program code always be consistent" is onerous, and, in my opinion, harmful.

When I write code, I often start with sketches that cannot work and cannot compile while I think things through, and then mold them into working code. Think about it as converting comments to code. If an editor didn't let me do that (and likely wouldn't provide any help, because I'm writing comment prose and not "rich data" code ...), I'd open a text editor to write my plans. text editor.

I will restate my belief in a different way: Any benefit from "code as data" that cannot be applied to a textual representation, only ever manifests in extremely simple cases. I offer as support for this belief, the history of visual and rich data tools over the last 30 years, none of which manages to scale as well as text based processes, most of them scaling significantly worse (which is often explained away by critical mass, but there are enough successful niche tools that I think this explanation is unacceptable).

</comment></comment></comment></comment><comment><USER13> I like to read about various problems in language design, as someone who is relatively naive to its deeper intricacies it really helps broaden my view. That said I have seen a trend towards adding various bells and whistles to languages without any sort of consideration as to whether it actually, in a measurable way, makes the language better.

The downside to adding an additional feature is that you are much more likely to introduce leaky abstraction (even things as minor as syntactical sugar). Your language has more "gotchas", a steeper learning curve, and a higher chance of getting things wrong or not understanding what is going on under the hood.

For this reason, I have always appreciated relatively simple homoiconic languages that are close-to-the-metal. That said, the universe of tools and build systems around these languages has been a growing pile of cruft and garbage for quite some time, for understandable reasons.

I envision the sweet spot lies at a super-simple system language with a tightly-knit and extensible metaprogramming layer on top of it, and a consistent method of accessing common hardware and I/O. Instant recompilation ("scripting") seamlessly tied to highly optimized compilation would be ideal while I am making a wishlist :)

<comment><USER14> Ever heard of K?

<comment><USER15> Is there a free version? I was interested I was interested in learning it a few years ago but couldn't find a version that was free for both commercial and non-commercial use, which tempered my enthusiasm.

<comment><USER16> To my knowledge, there isn't a full OSS implementation of K/Q. I do know of a K5 interpreter in JS [1] but otherwise I've only been able to find the free for personal use 32 bit Q distribution.

[1] [https://github.com/JohnEarnest/ok](https://github.com/JohnEarnest/ok)

<comment><USER17> Kona implements K3 according to its github.

</comment></comment></comment></comment></comment><comment><USER18> All this and handling overflow still doesn't make the list. Had it been the case that easy considerations for overflow were baked into C back then, we probably wouldn't be dealing with hardware where handling overflow is even more difficult than it would have been on the PDP-11. (On the PDP-11, overflow would have trapped.) At the very least, it would be the norm for compilers to emulate it whether there was efficient machine-level support or not. However, that didn't happen, and because of that, even Rust finds it acceptable to punt on overflow for performance reasons.

<comment><USER9> _On the PDP-11, overflow would have trapped._

On the DEC VAX, overflow could be set to trap, based on a bit mask at the beginning of each function, but that was not the case on the PDP-11. Nobody used that feature. I once modified the C compiler for the VAX to make integer overflow trap, and rebuilt standard utilities. Most of them trapped on integer overflow.

If you want arithmetic to wrap, you should have to write something like

        n := (n + 1) mod (2^32);

Let the optimizer figure out there's a cheap way to do that.

</comment></comment><comment><USER19> [Aside: Why do I have the Whiley ([http://whiley.org/about/overview/](http://whiley.org/about/overview/)) link marked seen?]

I was mildly curious why Graydon didn't mention my current, mildly passionate affair, Pony ([https://www.ponylang.org/](https://www.ponylang.org/)), and its use of capabilities (and actors, and per-actor garbage collection, etc.). Then, I saw,

" _I had some extended notes here about "less-mainstream paradigms" and/or "things I wouldn't even recommend pursuing", but on reflection, I think it's kinda a bummer to draw too much attention to them. So I'll just leave it at a short list: actors, software transactional memory, lazy evaluation, backtracking, memoizing, "graphical" and/or two-dimensional languages, and user-extensible syntax._"

Which is mildly upsetting, given that Graydon is one of my spirit animals for programming languages.

On the other hand, his bit on ESC/dependent typing/verification tech. covers all my bases: " _If you want to play in this space, you ought to study at least Sage, Stardust, Whiley, Frama-C, SPARK-2014, Dafny, F∗, ATS, Xanadu, Idris, Zombie-Trellys, Dependent Haskell, and Liquid Haskell._ "

So I'm mostly as happy as a pig in a blanket. (Specifically, take a look at Dafny ([https://github.com/Microsoft/dafny](https://github.com/Microsoft/dafny)) (probably the poster child for the verification approach) and Idris ([https://www.idris-lang.org/](https://www.idris-lang.org/)) (voted most likely to be generally usable of the dependently typed languages).

<comment><USER20> Indeed, I would say that capability-safety is the next plateau after memory- safety, but most languages are only barely glimpsing the capability horizon.

<comment><USER21> This is personally one of my major pet peeves, because I like to write secure code, and I think you very rapidly end up half-reconstructing capabilities work if you do, and it is not hard to notice that you basically get _no_ help whatsoever from languages. It is still clearly a nearly-invisible problem to the vast majority of developers. You need something almost Haskell class simply to assert "Please, at least provide me some evidence that you ran _some_ sort of permission check." to access a resource.

<comment><USER22> For "you ran _some_ sort of permission check" I'm a great fan of the React.js `dangerouslySetInnerHTML` interface, which accepts a corresponding `{__html: ...}` object that has at least nominally been properly vetted.

</comment></comment></comment></comment><comment><USER19> " _Writing this makes me think it deserves a footnote / warning: if while reading these remarks, you feel that modules -- or anything else I'm going to mention here -- are a "simple thing" that's easy to get right, with obvious right answers, I'm going to suggest you're likely suffering some mixture of Stockholm syndrome induced by your current favourite language, Engineer syndrome, and/or Dunning–Kruger effect. Literally thousands of extremely skilled people have spent their lives banging their heads against these problems, and every shipping system has Serious Issues they simply don't deal with right._"

Amen!

</comment><comment><USER23> So Graydon works at Apple on Swift?

Wasn't he the original designer of Rust and employed at Mozilla?

Surprised that this move completely went under my radar

<comment><USER24> That's how he likes it, to be honest. He doesn't want it to be some statement about Rust or Swift; he left Rust long ago, did some other stuff for a while, and there's only so many "work on a programming language" jobs out there.

In general the Rust and Swift teams are very friendly with one another, and have shared several devs.

<comment><USER23> Sure. He was very impressively neutral and rational about Monotone as well.

</comment></comment></comment><comment><USER25> The blurring of types and values as part of the static checking very much speaks to me.

I've been using Typescript a lot recently with union types, guards, and other tools. It's clear to me that the type system is very complex and powerful! But sometimes I would like to make assertions that are hard to express in the limited syntax of types. Haskell has similar issues when trying to do type- level programming.

Having ways to generate types dynamically and hook into typechecking to check properties more deeply would be super useful for a lot of web tools like ORMs.

<comment><USER19> Check Idris ([https://www.idris-lang.org/](https://www.idris-lang.org/)) and if you have a chance, work through the Idris book, _Type Driven Development with Idris_ ([https://www.manning.com/books/type-driven-development- with-i...](https://www.manning.com/books/type-driven-development-with-idris)).

</comment></comment><comment><USER26> I would love to see some advancements into distributed, statically typed languages that can be run on across cluster, and that would support type-safe, rolling deployments. One would have to ensure that state could be migrated safely, and that messaging can still happen between the nodes of different versions. Similar to thinking about this 'temporal' dimension of code, it would be cool to see us push versioning and library upgrades further, perhaps supporting automatic migrations.

<comment><USER27> Have you seen Alice ML?

It's a Standard ML variant that includes serialization of types and support for distributed programming.

[1] [http://www.ps.uni- saarland.de/alice/manual/tour.html#distrib...](http://www.ps.uni- saarland.de/alice/manual/tour.html#distribution)

<comment><USER26> How does it handle heterogeneous clusters that might have different versions of code running? Or is it like Cloud Haskell where you have to bring everything down when deploying?

</comment></comment></comment><comment><USER28> Interesting to see the mention of effect systems. However, I am disappointed that the Nim programming language wasn't mentioned. Perhaps Eff and Koka have effect systems that are far more extensive, but as a language that doesn't make effect systems its primary feature I think Nim stands out.

Here is some more info about Nim's effect system: [https://nim- lang.org/docs/manual.html#effect-system](https://nim- lang.org/docs/manual.html#effect-system)

</comment><comment><USER29> Fantastic article. This is the kind of stuff I go to Hacker News to read. Had never even heard of half of these conceptual leaps.

</comment><comment><USER30> I would have preferred a more informative HN title, instead of a semi- clickbaity "What next?", e.g.

"The next big step for compiled languages?"

<comment><USER31> Not everyone writes exclusively for the HN audience.

<comment><USER32> I think this is more of a complaint about HN's title policies.

</comment></comment></comment><comment><USER33> It's interesting that he doesn't want to draw too much attention to actors while they are prominent in Chris Lattner's manifesto for Swift [1]

[1] [https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9...](https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782)

<comment><USER19> Actors are a bit of a off-the-wall paradigm ([https://patterns.ponylang.org/async/actorpromise.html](https://patterns.ponylang.org/async/actorpromise.html)), and I'm (as an old network protocol guy) not sure I'm happy with the attempts to make message passing look like sequential programming (like async/await).

I kinda see where Graydon is coming from. I have this broken half-assed Pony parser combinator _thing_ staring at me right now.

</comment></comment><comment><USER34> I know I am basically dangeling meat into lions den with this question; How has PHP7 done in regards to the Modules section or modularity he speaks of?

I am interested in genuine and objective replies of course.

(Yes your joke is probably very funny and I am sure it's a novel and exciting quip about the state of affairs in 2006 when wordpress was the flagship product)

<comment><USER35> > the state of affairs in 2006 when wordpress was the flagship product

Does PHP have a different flagship product now?

<comment><USER36> It doesn't. WordPress is still the elephant (heh, elePHPant…) in the room.

PHP has other significant projects built on it of course, but WordPress is a behemoth nothing can hope to beat.

</comment></comment></comment><comment><USER37> I think at some point we will get to projection editors being mainstream for programming, and eventually things that we normally consider user activities will be recognized as programming when they involve Turing complete configurability. This will be an offshoot of more projection editing.

I also think that eventually we may see a truly common semantic definitional layer that programming languages and operating systems can be built off of. It's just like the types of metastructures used as the basis for many platforms today, but with the idea of creating a truly Uber platform.

Another futuristic idea I had would be a VR projectional programming system where components would be plugged and configured in 3d.

Another idea might be to find a way to take the flexibility of advanced neural networks and make it a core feature of a programming language.

</comment><comment><USER38> What would be a good book / website to learn the concepts & nomenclature in order to understand the advanced language discussions in HN like this one?

<comment><USER39> I can't attest to either, having not read them, but you might try Bob Harper's "Practical Foundations for Programming Languages", or Benjamin Pierce "Types and Programming Languages".

<comment><USER40> I can vouch for TaPL - I can see it on my bookshelf from here. It's a great overview of the foundational concepts in PLT; Pierce's style is remarkable, he writes the most readable academic text I've ever seen.

(I also own & admire his _Basic Category Theory for Computer Scientists_ ; I'm yet to brave his _Advanced Topics in TaPL_ \- I'm sure it's very good, but the contents list intimidates me.)

</comment></comment></comment><comment><USER41> it's interesting that Rust isn't mentioned once in his post. i wonder if he's disheartened with the direction his baby went.

<comment><USER42> People often speculate about this, which boggles me since graydon remarks positively on the current state of Rust all the time.

[http://graydon2.dreamwidth.org/247406.html](http://graydon2.dreamwidth.org/247406.html)

[https://twitter.com/graydon_pub/status/886212237987368960](https://twitter.com/graydon_pub/status/886212237987368960)

He even addresses the changes to the runtime:

[https://twitter.com/graydon_pub/status/705226109856526336](https://twitter.com/graydon_pub/status/705226109856526336)

<comment><USER43> Just to add (written just after 1.0): [http://graydon2.dreamwidth.org/214016.html](http://graydon2.dreamwidth.org/214016.html)

I think the above post indicates that he is extremely proud of how Rust turned out.

</comment></comment></comment><comment><USER44> I'm surprised build time wasn't on the list.

Curious and can't find anything: what's the most complex golang program out there, and how long does it take to compile?

<comment><USER45> jujud is commonly used as a benchmark for the Go compiler / linker due to being probably the biggest open source project. Can't find the actual compile times right now though, only relative figures.

</comment></comment><comment><USER46> LtU thread: [http://lambda-the-ultimate.org/node/5466](http://lambda-the- ultimate.org/node/5466)

</comment><comment><USER47> About units and dimensionality, AdaCore tried something in Ada with GNAT : [http://www.adacore.com/adaanswers/gems/gem-136-how-tall- is-a...](http://www.adacore.com/adaanswers/gems/gem-136-how-tall-is-a- kilogram/) and [http://www.christ-usch- grein.homepage.t-online.de/Ada/Dimens...](http://www.christ-usch- grein.homepage.t-online.de/Ada/Dimension/Physical_units_with_GNAT_GPL_2013-AUJ35.1.pdf)

</comment><comment><USER48> Extra credit for whoever implements logic proofs on concurrent applications.

<comment><USER49> Languages designed for safety-critical realtime applications do just that. Well, they don't use _proofs_ as proofs generally have a bad cost/benefit ratio (even for sequential programs), but they do use temporal logics that easily deal with concurrency, which they then verify mostly automatically. Temporal logics were introduced to CS in the late '70s, have resulted in at least two Turing awards, and have enjoyed some success in industry.

<comment><USER19> Do you have links?

I'm aware of TLA+ and (Jay Misra's) Unity ([https://en.wikipedia.org/wiki/UNITY_(programming_language)](https://en.wikipedia.org/wiki/UNITY_\(programming_language\))), but I haven't seen any other uses of temporal logics. (The lengths people will go to in order to get away from box and diamond...)

<comment><USER49> Take a look at Esterel[1], and its current incarnation, SCADE[2], which is used for avionics.

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

[2]: [http://www.esterel-technologies.com/products/scade- suite/](http://www.esterel-technologies.com/products/scade-suite/)

</comment></comment></comment></comment><comment><USER50> whats wrong with software transactional memory?

<comment><USER51> Nobody figured out how to implement it efficiently yet.

<comment><USER52> Haskell's STM is not efficient?

<comment><USER51> Haskell is not efficient with all these thunks and memory allocations.

Maybe the way Haskell does STM is efficient relatively. However, you cannot port that to C/C++/Java/C#, because they do not provide the type system to make it safe.

Maybe Rust can deliver. A quick search gives me rust-stm [0]. All these disclaimers in the README looks discouraging, though. For example, "Calls to atomically should not be nested", but isn't that the whole point about _composable_ STM?

Repeating transactions is a no-go, because it does not mix well with side effects. Thus, we need a lock-everything-required scheme. You do not want to expose this in the type system, because it explodes everywhere and gets really tiresome. Thus you need a whole-world analysis to find out what is "required" for a transaction. That breaks modular compilation and is inconvenient in general. In general, I don't see how this could work even a very high level.

[0] [https://github.com/Marthog/rust-stm](https://github.com/Marthog/rust-stm)

<comment><USER50> Yes, in a non-pure type system, you are "on your honor" to not cause side effects. Clojure made STM a first-class language feature despite this [https://clojure.org/reference/refs](https://clojure.org/reference/refs)

Second, the problems with impurity you listed are exactly solved by Haskell. Just because "you cannnot port that to x/y/z" language should've be counted against the haskell language.

We are talking about transactions here, but you're worried about thunks and memory allocations, and comparing this to java? It seems like you've simply decided Haskell is categorically slow, regardless of the context we're talking about.

</comment></comment></comment></comment></comment><comment><USER53> No type system improvements to support concurrency safety?

<comment> iso-8859-1 I think dependent types is next big step, and it also blurs the line between compilation and runtime. This will enable applications to do domain specific optimizations since types become so much more expressive. Purity allows for automatic parallelization. What Edward Kmett does in C++ here: [https://www.youtube.com/watch?v=KzqNQMpRbac](https://www.youtube.com/watch?v=KzqNQMpRbac) could be the default for all computation. On a modern computer, data parallelism is free, since SIMD instructions take just as long as any other instruction.

</comment></comment><comment><USER54> Can someone edit the title to something clearer? Thanks!</comment>


The End of Spectrum Scarcity (2004) - <AUTHOR> https://spectrum.ieee.org/telecom/wireless/the-end-of-spectrum-scarcity <comment><USER2> Even if we get cognitive radio and share spectrum there are still fundamental and engineering limits that mean spectrum will remain scarce. You're either sharing one spectrum with the entire world for HF (because of ionosphere bouncing) or everything that is in line of sight for the vast majority of the spectrum. That means a _lot_ of people are using the same 0.1-18 GHz. Once you get above 18 GHz or so then the propagation gets a lot worse, so it's less than even line of sight, but engineering problems with phase error start meaning higher order modulations are much more difficult to achieve.

Spectrum is always going to be scarce. That's why cables and fibers are always going to be important. Each one allows you to use the entire span all to yourself.

<comment><USER3> Agreed. The title is disappointing, especially coming from the IEEE.

Anybody who works on radio quickly understands that the radio spectrum is the most precious most scarce resource on the planet.

<comment> at-fates-hands Not knowing much about radio spectrum, but its a finite resource right? There's no way to expand the spectrum, or do something similar like what they did in the early days of wireless technology where they transitioned from TDMA (time division multiple access) to CDMA (code division multiple access) in order to expand the number of user you can put on a data stream.

Am I right to look at radio spectrum as a finite resource?

<comment><USER4> Those examples are ways to use the spectrum more efficiently. But the amount we have does not change.

It is finite indeed. But it's also not something that's consumable. Imagine it as a fixed sized room. If you move stuff out of a corner you can reuse it infinitely, but there can only be so much stuff in there on a particular moment.

</comment></comment></comment></comment><comment><USER5> DARPA Spectrum Collaboration Challenge[1] spent 3 years exploring this space with SDR + AI in a gamified way[2] and announced its winner last year[3].

[1] [https://www.darpa.mil/program/spectrum-collaboration- challen...](https://www.darpa.mil/program/spectrum-collaboration-challenge)

[2] [https://www.youtube.com/watch?v=-a-N8MiMqz0](https://www.youtube.com/watch?v=-a-N8MiMqz0)

[3] [https://www.darpa.mil/news-events/2019-10-24](https://www.darpa.mil/news- events/2019-10-24)

</comment><comment> d-sc If there is more capacity available, people will use it.

For instance, I happily stream videos and FaceTime over cellular quite a bit now. Even though I was plenty happy without that capability and don't really mind when the cell service isn't good enough for it to work.

</comment><comment><USER6> How does signal processing change when you know that part of the signal is much more likely to arrive intact than others? Do you use it for more error correction, or do you send multiple classes of traffic in each message? Like the color channels on a black and white TV signal?

I know a little bit of theory but I have a big gap in broad spectrum scenarios.

<comment><USER3> Bandwidth is physically bounded by frequency * log(noise ratio). As long as you've got a great signal, much better than what you can decode, you can increase the bandwidth.

The most common example is broadband. The 2 MHz band is split in a hundred independent bands of 20 MHz. Each one of the channel is adjusted independently to maximize bandwidth. [https://en.wikipedia.org/wiki/G.992.3](https://en.wikipedia.org/wiki/G.992.3)

<comment><USER6> We are talking about software defined radio though. How do these facts apply when there are no bands anymore? When collisions are avoided probabilistically instead of by partitioning?

<comment><USER7> No change. Just because your radio is "software defined," doesn't change physics and signal processing math. There are 'best' ways to use a given piece of spectrum, and while a SDR can make your hardware more flexible, it can't change that the most efficient way to use spectrum is usually to have a dense set of subcarriers modulating amplitude and phase. By avoiding a strict multiple-access protocol on a band, everything just gets worse; probabilistic back off is inefficient vs hard-scheduling. Every wireless system I've worked on (satellite radio, WiFi, LTE) has been very spectrum constrained, so I dont really believe in this future where spectrum is cheap.

<comment><USER8> In some sense,mesh WiFi doesn't seem spectrum constrained(considering home use) - just install enough mesh AP's.

<comment><USER9> Won't work unless the AP's scrupulously adhere to protocol to avoid interference. In practice the 2.4GHz interference has became tragical. In European high density housing, you are likely to have precipitous speed drop moving only across the room from the AP or behind one wall.</comment></comment></comment></comment></comment></comment>


Nepal Human Hair Solar Panel Hoax (CraigHyatt) - <AUTHOR> http://sites.google.com/site/edwardcraighyatt/hairsolarpanelnepal <comment><USER2> Isn't it amazing that "electromagnetic" had 21 upvotes (here: <http://news.ycombinator.com/item?id=813103> ) saying "The science is rather sound on this; ..." and then proceeding to try to justify why this seems right with a bunch of nonsense? Or was he joking as well? I can't tell for sure...

<comment><USER3> I was having a little fun at others' expense. I never said it wasn't a hoax, but the science _is_ there, but it isn't 'here' in the sense that it's usable today. I got upvoted talking about photosynthesis with no mention of photovoltaics in an article about a PV cell.

Chlorophyll is currently being developed as a low cost dye in solar cells (the dye is the photoelectric material sandwiched in the middle that produces the electricity). Melanin itself is currently of interest due to it enabling the standard dyes (silicon dioxide, titanium dioxide, etc) to capture electrons they shouldn't be able to, it somehow takes low-energy light (even infra-red) and kicks it up a notch for the standard dye to capture.

Melanin in itself has a few amazing properties. It's apparently photoelectric right through from IR to Gamma rays, and also alpha, beta and neutrons produce the same effect in it. The IR and UV effects are the best features, making it an efficiency booster in existing solar panels by one means or another. The fact that it can potentially produce electricity through radiation has a whole other interesting factor to it, it creates the potential for a direct radiation->electricity just as solar cells have provided for solar energy (coal, oil and natural gas are just dead plants and animals that harvested solar energy a million years ago, wind is the thermal effect from solar, hydroelectric comes from rivers that came from rain that came from a heated ocean, etc). The two raw power sources we have are solar and nuclear (I suppose technically tidal and geothermal are raw sources too, but neither are developed enough), skipping the middle-men, so to speak, in the process is likely to be crucial in our future.

Melanin photovoltaic cells could enable the direct harvesting of radiation to produce electricity from many sources. Either stray radiation in a nuclear reactor (basically as radiation shielding that makes you money), or as an alternative to RTG's, but currently its greatest use in this field could be harvesting energy from nuclear waste, both the thermal products and the ionizing radiation. It's also of interest for space, as ionizing radiation there is immense, the sun emits vast amounts of x-rays constantly, we're just buried under our planets radiation shields.

The science _is_ there for melanin as I said, but it'll likely take a lot of R&D before a melanin-based cell is on the store front, and it likely won't appear on its own to the general public as the uses of melanin-based cells are likely to be found where civilians are not (IE radioactive places or space).

<comment><USER4> You weren't having fun at other's expense, you were had just like everyone else. You never said it wasn't a hoax because you didn't know it was a hoax.

There are two lessons to be had from this, and the recent facebook fax hoax 1) Traditional Journalism is good because they do fact checking and blogs do not. 2) The real time web is easily hackable.

People don't take the time to do research. They just read and accept. Slower news helps it be more real. Most of what comes into our brains now is just forgotten anyway. It may actually be better for us to read stuff a week or two after it comes out so it has time to be vetted by the community.

We may be doing ourselves a disservice by staying so "up" on the news because we could be polluting our brains with false information. We should be in constant doubt of everything we read on blogs, but unfortunately, we are not.

<comment><USER5> _There are two lessons to be had from this, and the recent facebook fax hoax 1) Traditional Journalism is good because they do fact checking and blogs do not._

What? The original story was published by the Daily Mail, and it appears to have been debunked by a blogger.

<comment><USER6> Let's not even mention the fact that on the day it was debunked, CNN was running a story about a terrorist attack on Washington, D.C. that turned out to be a Coast Guard training exercise.

[http://blogs.abcnews.com/politicalpunch/2009/09/white- house-...](http://blogs.abcnews.com/politicalpunch/2009/09/white-house-blames- media-for-scare-resulting-from-coast-guard-exercise.html)

<comment><USER4> The exception proves the rule? A blogger righted the issue with Dan Rather a couple years ago as well. I suppose we have to look at the majority case here and the majority of bloggers are regurgitators. The news regurgitates a lot too. I have lost a lot of faith in our institution of media lately.

The journalistic ethic is going in the toilet because it doesn't spur ratings...

<comment><AUTHOR> There are several 'classes' of bloggers.

There are those who do their homework, have writing skills and do their utmost to produce quality content, there are the plagiarists that will copy whole blogs verbatim and pass them off as their own, in between there is everything else.

To put all bloggers in the same corner is the same as saying that all people are unethical. The 'majority' may be right, it may be off but my feeling is that there is plenty of excellent content out there and plenty of crap. I wouldn't be so fast to discard the majority, especially in other languages than English the amount of regurgitation is less than you'd expect.

Regurgitators = thinly veiled plagiarism, what in school would be called 'rewriting' instead of 'writing'.

And newspapers that print bloomberg or reuters stories are also regurgitators.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> It happens all the time that people do not realize what the actual driver is in an experiment. (The cuprous oxide vs the hair mat.)

For example look at: <http://www.physorg.com/news171643486.html>

I don't know anything about physorg.com, it sounds like they should know science - except they don't. The electricity does not come from the tree, it comes from the metal probes.

Cold fusion has the same problem. One person reported how a certain batch of palladium worked great and made energy, but now the palladium is used up, and new batches don't work.

His mistake is that the palladium and the cold fusion had nothing to do with it. Palladium is sometimes refined from nuclear waste, and that batch was slightly contaminated.

Doing science is hard, especially correcting for all the variables. Very few people learn how to do it properly.

<comment><USER8> Actually, if you read the article, they mention using two probes made of the same metal to eliminate any current generated by the differences in redox potential between them.

<comment><USER7> There is still a difference. The probes are placed in different things, so the two probes have differing ability to oxidize.

Oxidation of a metal is a much more likely source of electricity than a tree, so much so, that they need a much better experiment before I'll be convinced that the tree is making electricity.

For example, let it run for a long time and check for any evidence of corrosion.

Are there metals that don't corrode? Perhaps palladium?

They could also try a variety of different metals for the probes (both at the same time) and see if they get different voltage readings.

</comment></comment></comment><comment><USER9> It's instructive to review the comments from the original posting on HN (e.g., _The science is rather sound on this..._ ):

<http://news.ycombinator.com/item?id=813103>

<comment><AUTHOR> I run a chat server dedicated to RE and we had our 'hoax' flag up just about immediately.

Kudos to Craig for taking the time and effort to put this one to rest.

Every couple of weeks there is some piece in the news about some renewable energy breakthrough by some teenager, and every time it is either a hoax, it doesn't scale, it produces piddly little bits of power, the economics don't work out or they misunderstood the physics (or any random combination of these).

I'm really happy that kids are interested in renewables, it's a fantastic way to get into science and it is also good to have consciousness raised about our 'footprint'.

But I really wished that the press would fact check this stuff a bit more, one of these days somebody is going to have a real breakthrough and the public will react with 'meh', just another hoax.

Looking for renewable energy source in unlikely places (the windbelt for instance) is interesting because there are plenty of opportunities to get press and sometimes even funding, even if your physics is lousy. The hope humanity has for solving our dependence on oil coupled with dirt cheap renewable energy is what fuels this kind of response.

In practice, engineering is hard and it pays off to do your homework.

I'm curious if the kids that did this will now go on the defense or if they will own up to what the did.

And if the dailymail will issue a retraction.

<comment><USER10> For what it's worth, I recall the top HN comment initially being something about the paper printing hoaxes.

<comment><AUTHOR> you are correct.

<http://news.ycombinator.com/item?id=813116>

</comment></comment></comment></comment><comment><USER11> This debunking article is convincing. However, it begins by calling the news story a hoax and then continues to establish why such a device would not work as advertised but never shows any evidence that the story is a hoax.

<comment><USER12> what? if you agree that such a device can't work, how can that "news article" NOT be a hoax?

<comment><USER13> A hoax implies deliberate fraud. Many scientific theories turn out to be wrong, but are not hoaxes. Newtonian mechanics or the Bohr atom model, for example.

<comment><USER14> This was not the case of a theory being wrong. He's making the case that the device they show can not possibly have the characteristics the makers claim. And it's hard to say that's not deliberate. At a minimum grossly negligent.

The experiments that lead to the development of Newtonian mechanics (the Copernican laws, for example) are still valid. It's just their interpretation that has changed.

</comment></comment></comment></comment><comment><AUTHOR> If anybody wants to get involved in DIY renewable energy then probably <http://www.fieldlines.com/> is a good place to start.

</comment><comment><USER13> _If hair is a non-conductor, then it cannot be a semiconductor_

False. For example, pure silicon is non-conductive, but when you add slight boron or phosphorous impurities it becomes a semiconductor. So it's not impossible that hair has semiconducting properties when it absorbs salt water.

Of course, the claim of human hair solar is crap. But debunkers should be extra-careful not to make bogus claims of their own.

<comment><USER8> Then again, silicon is an atomic crystal, while hair's structure is defined on the cellular level, which makes doping silicon much more practical than doping hair. This is on top of the problem that solids without an atomic lattice of some form tend to have trouble allowing any kind of electron movement at all, regardless of what chemicals you add to it (there are quite a few exceptions, like chlorophyll, but even those tend to be well-defined at the molecular level).

Also, as the author mentions, hair soaked in salt water becomes conductive, not semiconductive - current running through it is simply passed on by the salt water - but this conductivity has nothing to do with the hair and everything to do with the water.

</comment></comment><comment><USER15> Okay, I was fooled. It certainly sounded feasible. Perhaps the only pointer for those not in the industry would be that he was inspired by "...a book by physicist Stephen Hawking, which discussed ways of creating static energy from hair"

That'd be the only iffy sentence that could have caught my eye. But it didn't. Caveat lector.

<comment><AUTHOR> Static != 2A current through a bunch of hair.

In fact, the whole reason hair will build up static is _because_ it is such an excellent insulator.

edit: about the conductivity of hair:

<http://www.rafischer.com/hairtest.htm>

edit2: why people think hair conducts well:

Thomas Edison is often quoted as having said the first working filament was a human hair.

He did try one, but it didn't work, what did work was a filament made from a small strip of carbonized bamboo (effectively a 'carbon wire resistor').

This thread was 'thinner than a human hair'.

Thus reinforcing the words hair and filament together again.

much interesting reading on:

<http://en.wikipedia.org/wiki/Incandescent_light_bulb>

</comment></comment><comment><USER16> What I don't quite get: what is the point in making up such a thing?

<comment><USER12> media exposure to underdeveloped countries?

i'm just puzzled because right from the start i had the strong impression that this was a hoax. it always is, at least when kids from some random country claim to have solved major problems.

</comment></comment><comment> onreact-com This is a follow up on this submission:

"Teenager invents solar panel made from human hair (dailymail.co.uk)"

<http://news.ycombinator.com/item?id=813103>

</comment><comment> onreact-com Yeah. Read here as well:

[http://community.discovery.com/eve/forums/a/tpc/f/9701967776...](http://community.discovery.com/eve/forums/a/tpc/f/9701967776/m/39719686201)

The Museum of Hoaxes is lagging a little:

[http://www.museumofhoaxes.com/hoax/weblog/permalink/solar_pa...](http://www.museumofhoaxes.com/hoax/weblog/permalink/solar_panel_made_from_human_hair/)</comment>


A Look At April's Mass SQL Server Injection Attack  - <AUTHOR> http://blogs.ittoolbox.com/c/programming/archives/a-look-at-aprils-mass-sql-server-injection-attack-for-aspnet-sql-server-sql-server-environments-25388

<comment><USER2> Really annoying. Why can't people build things to help others not hinder them?

<comment><USER2> I spent several days in April/May fixing problems caused by this SQL hack at the place where I am contracting :(</comment></comment>


National parks face years of damage from government shutdown - <AUTHOR> https://www.nationalgeographic.com/environment/2019/01/why-national-parks-trashed-during-government-shutdown/ <comment><USER2> Really sad. I would think if there is no one to take care of the parks then it's only common sense to have them closed to tourists.

</comment><comment><USER3> In Canada we have a good parks system and yet I must admit that the US park system is phenomenally well run and contains so much diversity. I suspect that us visitors take for granted how much work is involved in maintaining the cleanliness and illusion of untouched solitude. We are so fortunate to be able to enjoy it and I hope any shutdown damages are minimal.

</comment><comment><USER4> I bridle at any article that makes claims like this. if a few weeks of shut down causes years of damage and you aren't a nuclear power plant, I call BS. people's critical thinking skills go out the window when it's politically convenient to believe garbage.

<comment><USER5> TFA clearly states the ways in which this shutdown could lead to lasting damage. I would encourage you to think critically about the effect of widespread litter or sewage spills or off-trail hiking in a national park setting. Additionally think of facilities in inhospitable conditions.

The comparison to nuclear reactors is odd. It suggests to me you think National Parks are a more trivial operation than a power plant. I think they are far too different to make this comparison.

A pet goldfish is not as complicated to keep alive as a power plant but if you don't feed it then it dies.

<comment><USER6> Are you actually bothered by widespread litter or sewage spills or off-trail hiking, or is that just something convenient for a political fight? Actual concern would mean you want to save Organ Pipe National Monument and Big Bend National Park by building a wall to protect those fragile desert ecosystems. The shutdown, assuming it results in a wall, would prevent lots of lasting damage.

<comment><USER5> I do care about off trail hiking in _all_ national parks because of the obvious damage that causes. I also care about preventing littering _everywhere_. Including national parks. My concern for these topics is unrelated to my stance on a border wall.

I don't appreciate your unfounded implication that my concern for national parks is somehow politically motivated or excludes specific parks.

I also don't appreciate your attempts to drag this conversation off topic. The article is about lasting damage to national parks due to a government shutdown. The article is not about a wall or the border.

<comment><USER6> Superficially, the article is about lasting damage to national parks due to a government shutdown.

Ask yourself why the article was written. Pay attention to the fact that the damage is blown all out of proportion. The article lists things that aren't long-term (unclean toilets and unemptied trash) and other things (walking off trails) that are a normal occurrence during non-shutdown times.

There is no question in my mind that this article was not written with any legitimate concern for national parks getting damaged. The most generous assumption would be ordinary fearmongering because a writer needs to catch eyeballs.

<comment><USER5> The most generous assumption is that the article was written in good faith and that the government shutdown has a material effect on the parks as described.

</comment></comment></comment></comment></comment></comment><comment><USER6> That is nothing compared to the damage happening at the border. There are piles of trash, unauthorized trails carved through fragile ecosystems, fires, and human bodies. This shutdown is part of a fight over a wall that would protect several national parks and national monuments from this massive ongoing ecological damage.

[https://www.washingtonexaminer.com/park-service-illegals- des...](https://www.washingtonexaminer.com/park-service-illegals-destroying- federal-lands-unsafe-for-camping)

[https://www.desertinvasion.us/](https://www.desertinvasion.us/)

<comment><USER5> The border is not a national park. Your whataboutism is not compelling.

<comment><USER6> Big Bend National Park is on the border. BTW, it is a UNESCO designated Biosphere Reserve.

Organ Pipe National Monument is on the border.

They are being destroyed. The rest of the ecosystem, outside of those, is also worth protecting.

<comment><USER5> The border is not a park but there are parks on the border. Some parks are on the border but not all of them. Similarly squares are rectangles but not all rectangles are square.

Clearly the border is worth protecting and so are parks. I don't see anyone disputing that in this context. You seem to be arguing against a straw man.

Your original comment dismissed concerns about protecting parks off the border by changing the subject to border conditions. This is whataboutism and is a logical fallacy.

<comment><USER6> The non-border parks aren't suffering much unusual damage. That is alarmist nonsense. Toilets may overflow, and piles of trash will form around the trash cans, but this is pretty easy to fix.

The bit in the article about walking off of trails is particularly silly. People will do that or not, unaffected by the shutdown. Nothing will change. Meanwhile, that is actually a serious problem for the border parks. There we have all sorts of unauthorized trails crudely carved through fragile ecosystems.

It is perfectly legitimate to point out hypocrisy and insane priorities, and slapping a silly label like "whataboutism" on it does nothing to change that. I swear, there is something like Godwin's law for "whataboutism".

<comment><USER5> TFA clearly explains the ways in which parks are experiencing lasting damage due to the shutdown. This is happening regardless of their location relative to the border.

Please refute the claims in the article directly instead of dismissing them out of hand.</comment></comment></comment></comment></comment></comment>


R3 – High-performance URL router library in C - <AUTHOR> https://github.com/c9s/r3

<comment><USER2> Wow! My eyes popped out for a second when I saw my name there in the README. I wrote an alternative router for Rails ([https://github.com/stevegraham/rails/pull/1](https://github.com/stevegraham/rails/pull/1)) because I wanted to be able to generate links to parent and child resources automatically by reflecting on the routing table. I think this would be a useful feature for Hypermedia APIs. I'm currently working on implementing this in a project called Restafarian ([https://github.com/stevegraham/restafarian/blob/master/examp...](https://github.com/stevegraham/restafarian/blob/master/examples.md)). I couldn't see a way to do this with Journey (The existing Rails router) which is a deterministic finite state automaton, so I wrote one using a modified trie structure where the nodes also have a reference to their parent. It also happened to be a bit faster, which was a nice bonus, but it looks like they've made some changes to bring it to nearly the same performance characteristics.

<comment><AUTHOR> Hi! your implementation is inspiring to me. so I mixed some other ideas to implement this (for fun and experimentation).

this router library can be used for different purpose (outside of URL dispatching), although we don't gain so much performance from the point of view of each single request.

</comment></comment><comment><USER3> Is that seriously a performance issue for any real webapp?

<comment><USER4> (Pre-disclaimer: I think it's great that the author spent some time benchmarking and hacking, and I don't mean for this comment to tear down their work, but rather I'm just answering the above question which was also the first thing that came to my mind when I saw this.)

The slowest URL router benchmarked there[1] does 10462.0 runs per second, which is just under 0.1ms per run.

I'm not sure what performance is expected of Rails handlers but the first stackoverflow thread[2] that came up on a simple Google search had twitter doing 600 req/s across 180 instances which comes to 300ms per request.

By that math, the slowest URL router costs 0.033% of the request overhead.

Caveat: 300ms/req is slower than you'd like for an interactive website; real websites may have more complicated routing tables than this benchmark. Counter-caveat: 0.1ms is not enough to matter pretty much anywhere except for the stock market.

[1]: [https://github.com/c9s/r3#benchmark](https://github.com/c9s/r3#benchmark)

[2]: [http://stackoverflow.com/questions/373098/whats-the- average-...](http://stackoverflow.com/questions/373098/whats-the-average- requests-per-second-for-a-production-web-application)

<comment><USER5> In addition, if you were to replace the Rails router with a Ruby trie implementation, it would be even faster. (not that this is encouraged)

<comment><USER2> I wrote the trie implementation referenced in the benchmarks. I didn't do it for speed, I did it because I couldn't add the router functionality I needed using the existing underlying implementation.

<comment><USER5> Cool, nice work! I didn't actually look at the benchmark and was just making (perhaps poor) assumptions. I'd imagine it does come with a nice little performance boost though?

</comment></comment></comment></comment></comment><comment><USER6> Please don't use autotools, this is a prime example of why you shouldn't use autotools as the whole of autotools within the project is larger than the project, an alternative is a simple shell configure to check in env. A few other issues that I don't understand is why you made strndiff / strdiff, str_repeat, str_split it is the same as strncmp / strcmp, strcpy, strtok you just duplicated libc for some reason.

<comment><AUTHOR> The behavior of (strndiff / strdiff) is different from strncmp or strcmp. strn?cmp does not return the offset. they are different functions.

and in order to ship this package to deb, deploy to different platform, use autotools to test C features is a requirement. (we used to build the project with cmake before we use autotools)

<comment><USER6> Reading it again strdiff is the same as strspn, but your's doesn't actually handle c strings and reads past null. You can do feature tests yourself without pulling in the whole autotools mess: [http://git.musl- libc.org/cgit/musl/tree/configure](http://git.musl- libc.org/cgit/musl/tree/configure)

<comment><AUTHOR> Thanks! that helps!

</comment></comment></comment></comment><comment><USER7> This is the kind of stuff Ragel would be a good fit for.

</comment><comment><USER8> See also: [http://nikic.github.io/2014/02/18/Fast-request-routing- using...](http://nikic.github.io/2014/02/18/Fast-request-routing-using- regular-expressions.html)</comment>


Apple Security Guards Promoted to Full-Time Staff - <AUTHOR> http://www.pcmag.com/article2/0,2817,2477752,00.asp

<comment><USER2> This is an interesting move. Security work seems like the quintessential outsourced role - what does Apple know about hiring, training and maintaining a quality security force? It seems like a distraction from making hardware and software. If it makes sense from a plain bottom-line standpoint (economies of scale, etc) it seems like they would have done it a long time ago. So is this more like Cook just deciding to do it despite the higher costs? (Not that I don't think it's the right thing to do, I just know the pressures to increase profits)

<comment><USER3> Having worked in this field, I have noticed that when large companies have issues with their security people, it is almost always an issue with contract employees and noone from the company managing the situation close enough. There is also an added layer when you have contractors, sometimes miscommunication happens, sometimes it devolves into coverups.

When you employ the security guard directly you also can avoid attrition detracting from the familiarity the guards have with the property and procedures. They will also have more invested in making sure things go well for the company.

In these sort of transitions, often the existing contractor will work with the client to ensure a good transition so that they can maintain relations. In some cases they also will continue to hire guards who transition to FTEs after a period (temp-to-hire).

The reason that it does not happen that often is that the industry is used to contracting out for these employees and long introspective studies of physical security are expensive and often embarrassing.</comment></comment>


The Unexplained Fear Of Remote Employees - <AUTHOR> http://ramenapp.net/post/53b191df6231390002000000

<comment><USER2> Remote work has it's ups and downs. I have been remote for about 18 months now as a senior software engineer.

On the plus side you are way more productive. Working from home also means no time is lost in commute and depending on your team you can generally work whatever hours work well for you.

However there are some downsides.. specifically it can be a little lonely at times if there is no-one else at home. This isn't a problem short term but it can become one. Physically it can not be good as if you work from home there suddenly is very few reasons to leave, resulting in less exercise if you are not careful. etc.

That being said, I think overall it's important to be flexible , remote employees can be many times more productive than their 9-5 counterparts.

<comment><USER3> > However there are some downsides.. specifically it can be a little lonely at > times if there is no-one else at home.

I imagine so. But note that this isn't really a problem with remote work _per se_ ; it's a problem with working in a way that is different from what the vast majority of people do.

Once upon a time (before the Industrial Revolution) most people worked at home. The kind of loneliness you describe was rare, because home and its environs were where the people were.

Maybe there is a societal "hump" we need to get over. If more people worked remotely, then working remotely would become a more pleasant thing.

</comment></comment><comment><USER4> I have worked primarily remotely over the past 15 years as consultant, industry analyst, developer, statistician and writer. The settings have ranged from me being in about a 5% minority of a corporate workforce, to a small start-up that was formed as 100% remote, To solo freelance where physical presence at clients is largely my call.

While it has been a clear benefit on the productivity and family life balance side of the equation, I do feel that I have sometimes lost out to opportunities. Opportunities for career advancement, or interesting projects that would have been nurtured by the more subtle communication patterns and interpersonal bonds formed by extended in-person interaction with co-workers and higher level executives.

Life is full of trade-offs.

</comment><comment><USER5> I find this to be a very delicate balance, and it of course are heavily dependent on the tasks at hand. On one side you want peace and quiet, in order to concentrate, on the other hand you want close communication with your colleagues.

I think 37signals from lot of good answers to these concerns. I highly recommend reading from 37signals, Remote.

</comment><comment><USER6> There is one I work for colearnr.com ; the company is in London , UK . Awesome work environment . The best part of remote job is certainly the freedom , because you are most productive in environment which suits you the best . In a closed cabin offices you are put into a different environment which may or may not help you . We are also looking for people to join our company . So please feel free to contact ;)

</comment><comment><USER7> _Rule of Diversity: Distrust all claims for "one true way"._ \- Eric S. Raymond, The Art of Unix Programming (2003) [http://en.wikipedia.org/wiki/Unix_philosophy](http://en.wikipedia.org/wiki/Unix_philosophy)</comment>


F.B.I. Employees with Ties Abroad See Security Bias - <AUTHOR> http://www.nytimes.com/2015/01/04/us/fbi-employees-with-ties-abroad-see-security-bias.html <comment><AUTHOR> Hurts, don't it?</comment>