UTF-8 good, UTF-16 bad - <AUTHOR> http://benlynn.blogspot.com/2011/02/utf-8-good-utf-16-bad.html <comment><USER2> Broad backwards compatibility with ASCII is a strong reason to prefer UTF-8 in most applications, however I find the issues with UTF-16 are overstated and the advantages of it ignored.

"UTF-16 has no practical advantages over UTF-8" - UTF-16 is better - i.e., quite a bit more compact, since, e.g., Chinese characters always take 3 characters in UTF-8, for asian languages.

"A related drawback is the loss of self-synchronization at the byte level." - Maybe this is a problem, maybe not. Maybe the failure of UTF-8 to be self- synchronising at the 4-bit level is a problem is some circumstances. I don't mean to be flippant, but the wider point is that with UTF-16, you really need to commit to 16-bit char width.

"The encoding is inflexible" - I think the author has confused the fixed-width UCS-2 and the variable-width UTF-16.

"We lose backwards compatibility with code treating NUL as a string terminator." - Not true. NUL is a 16-bit character in UTF-16. Use a C compiler that supports 16-bit char width.

<comment><USER3> > "UTF-16 has no practical advantages over UTF-8" - UTF-16 is better - i.e., > quite a bit more compact, since, e.g., Chinese characters always take 3 > characters in UTF-8, for asian languages.

In some contexts that may matter. In other cases, you can expect enough ASCII mixed in to outweigh that effect. For example, on the Web though, if you're sending HTML, the savings from using 8 bits for the ASCII tags will nearly outweigh the cost of extra bytes for content text. Gzip shrinks that further to essentially no difference.

<comment><USER4> As I posted there, too, he also missed one very important plus in UTF-16: character counting. If you ensure there are no Surrogate Chars (which is a simple byte-mask comparison using every second byte (only!) as in: "0xD800 & byte == 0xD800" [using the entire range to avoid having to think about byte order]) in your array, you can be 100% sure about the character length just by dividing the byte-length in two. With UTF-8, you have to look at each and every byte one by one and count the number of characters to establish the actual char-length. Finally, given how rare the Supplementary Range characters are, the Surrogate Range check can be safely skipped in many scenarios, making it significantly faster to establish char lengths in UTF-16 than UTF-8.

EDIT: oh, and before any "semantic-nerd" comes along: I am fully aware that 0xXXXX are two bytes, so, if you want, read "two-byte" for every time I mention "byte" above... (doh ;))

<comment><USER5> Right, if you ensure that only ASCII characters are used in UTF-8, which you can check using 0x80 & byte == 0x00, counting the number of characters is easy. But to check that this condition holds, you need to iterate over the whole string anyway.

I don't see how this gives any advantage to either of the encodings. Both for UTF-8 and UTF-16 you have to implement some decoding to reliably count the number of characters.

<comment><USER4> Oh, and another thing is your argument only holds for ASCII - I hardly ever encounter pure ASCII data nowadays when I work with text. On the other hand, I _never_ have encountered a Surrogate Character except in my test libraries, either. Next, if you are working with pure ASCII, who cares about UTF-8 or -16? Last, you still need to scan every byte in UTF-8 for that, but only every second "two-byte" in UTF-16, which is half.

<comment><USER6> When you say 'ASCII' I guess you mean 'strings where all bytes have a decimal value in the range [0-127]', right? If so I agree that it's rare to encounter that, but the common use (however wrong) of ASCII is 'chars are in [0-255]', i.e. all chars are one byte; and that data is very common.

Thinking about it, I don't know what codepage the UTF-8 128-255 code points map too, if any, though; could you explain? If you treat UTF-8 as ASCII data (as one byte, one character, basically), does it generally work with chars in the [127-255] range.

<comment><USER4> 256 char ASCII is called "8-bit", "high", or "extended" ASCII. So, pure (7-bit) ASCII is the only thing you can hold in a "one-byte UTF-8 array". The 8th bit (or the first, depending on how you see it) is used to mark multibyte characters, i.e. any character that is not ASCII. So you only can represent 128 possible symbols into a UTF-8 character with length of one byte. In particular, UTF-8 maps these to ASCII (or, US-ASCII) characters, and the byte starts with a 0 bit (In other words, you cannot encode high ASCII into one UTF-8 byte.) For ALL other characters (no matter), the first bit in any (multi-)byte is set to 1. That's why it is easy to scan for length of ASCII chars in UTF-8, but not for any others.

<comment><USER6> Oh I see, thank you, it seems I was misinformed.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> Better discussion here, IMO: [http://research.swtch.com/2010/03/utf-8-bits- bytes-and-benef...](http://research.swtch.com/2010/03/utf-8-bits-bytes-and- benefits.html)

</comment><comment><USER8> > The Go designers knew what they were doing, so they chose UTF-8.

The authors of Go and authors of UTF-8 are more or less the same people, so the choice was no-brainer.

</comment><comment><USER9> I honestly had no idea there were parts of the development community that actually used and preferred UTF-16...

<comment><USER10> Anyone who programs in Java is using UTF-16. And in my experience very few Java programmers understand that UTF-16 is a variable length encoding.

<comment><USER11> Too few programmers know that UTF-8 is a variable length encoding: I've heard plenty assert that in UTF-8, every character takes two bytes, while claiming simultaneously they could encode _every possible_ character in it.

A bit broader: too few programmers understand the difference between a character set and a character encoding.

<comment><USER12> > too few programmers understand the difference between a character set and a > character encoding

why then they have the same names??? :)))

ps/ <http://www.grauw.nl/blog/entry/254> \- is this article ok? first in google by "charset encoding difference"

<comment><USER11> That article starts out OK and then suddenly tries to argue that you can use the terms interchangeably. You can not and you will drown in confusion if you try to. Just imagine that tomorrow, the Chinese introduce their own character set next to Unicode, but use UTF-8 to minimize the number of bytes it takes to represent their language (which makes sense, because the frequency of characters drops off pretty fast and some characters are much more common than others, so you'd like to represent those with one byte).

The fact that the HTTP RFC speaks of 'charset=utf-8' is explained by this part of the spec:

      Note: This use of the term "character set" is more commonly
      referred to as a "character encoding." However, since HTTP and
      MIME share the same registry, it is important that the terminology also be shared.

Why does MIME use the 'wrong' terminology? Perhaps because the registry is old and the difference between set and encoding was less obvious and relevant back then. Perhaps it was simply a mistake; a detail meant to be corrected. Perhaps the person that drew it up was inept. Who knows. It doesn't matter, it is still wrong. And don't get me started on the use of character set in MySql...

</comment></comment></comment></comment></comment><comment><USER13> I keep hoping a string API will catch on in which combining marks are mostly treated as indivisible. Handling text one codepoint at a time is as bad an idea as handling US-ASCII one bit at a time--almost everything it lets you do is an elaborate way to misinterpret or corrupt your data.

<comment><USER14> It's not so simple: it depends on what you're doing with the text. If you're not trying to do analysis with it, encoded text is more or less a program written in a DSL that, when interpreted by a font renderer, draws symbols in some graphical context. Depending on the analysis you want to do, you need varying amounts of knowledge. Perhaps you only need to know about word boundaries; perhaps you're trying to look things up in a normalized dictionary; maybe even decompose a word into phonemes to try and pronounce it. These require different levels of analysis, and one size won't fit all.

</comment></comment><comment><USER15> The article, at the end, claims that "ASCII was developed from telegraph codes by a committee." It turns out the story is much, much more complicated and interesting than that: <http://www.wps.com/projects/codes/>

</comment><comment><USER16> UCS2, even though being an outdated predecessor to UTF-16, has some unique qualities that make it useful for things like databases or other storage mediums that you are not mixing with a lot of low code point characters (like you do with XML and HTML markups).

One being that's fair for all languages with respect to size so when you may be storing your standard Chinese, Korean, Japanese characters.

When UTF-16 made UC2 variable length, a few of the nice things were lost, but when dealing a lot of the higher code point characters mostly, UTF-16 may save you space.

</comment><comment><USER12> may i dare make a conclusion with my observations? :)

utf-8 is good for network interchange and is de facto becoming standard.

utf-16 is not bad for internal storage of strings in memory or in database. not nesserily bad. maybe even better for some reasons

</comment><comment><USER17> Can someone link me to where python uses UTF-16? It was my understanding it defaulted to UTF-8.

<http://www.python.org/dev/peps/pep-3120/>

<comment><USER18> That PEP only refers to the encoding of the source (code) file, not to the encoding on how strings are stored in Python.

Edit: Your question might be answered at SO: [http://stackoverflow.com/questions/1838170/what-is- internal-...](http://stackoverflow.com/questions/1838170/what-is-internal- representation-of-string-in-python-3-x#1838285)

</comment></comment><comment><USER19> Correct me if I'm wrong, but I think Excel still outputs UTF-16 in some cases. I remember parsing generated .txt/.csv files and there were issues with it and it's endian order.

</comment><comment><USER20> Good read! I always HATE it when things complain that my visual studio _.c/_.h files are BINARY! WTF!

</comment><comment><USER12> and i find it fair that American characters require 2 bytes in Java as everybody else, not 1 as in utf-8! :)

<comment><USER21> You seem to be confusing "fair" with "equal". Treating everybody the same is not necessarily fair. It seems fair to me to have the most common characters be shortest. I don't have any evidence, but I would guess that Latin characters[1] are used most commonly.

[1] "Latin characters" is the proper term, not "American characters"

<comment><USER12> thanks! but i just tried to kid which i can't control sometimes.

anyway, i think that even if Latin chars weren't the most used in the world, it would be fair to keep them the primary charset for use in programming and markup languages, as no-one now complains that the international language of medicine is Latin, not, say, Chinese :) as computers started to be massively developed in America.</comment></comment></comment>


Replacing All The Things with Unite.vim - <AUTHOR> http://www.codeography.com/2013/06/17/replacing-all-the-things-with-unite-vim.html <comment><USER2>
        First my rationale behind loving this lil plugin. Not only is it a powerful interface for navigating my code, but it is a consistant interface. Once I get the muscle memory for navigating one thing (say buffers), I can use that to navigate all the things (say yank history).

Am I the only one that feels like vim just became emacs?

<comment><USER3> It has been going that way for quite a few years, maybe it is only natural.

</comment></comment><comment><USER4> It's hard to tell exactly what the features are, even after reading the article and the github README :(

<comment><USER5> Yeah, I was struggling working it out too, but eventually managed to use it and it's pretty great. I found that the file search works better than ctrlp (and you don't need to wait!), and other options like listing all open buffers and switching quickly between them is really great. Another interesting feature is the line search. I'm used to search using / but this one instead of highlighting the text as you type, it fuzzy searches and eliminate all _other_ lines. Pretty neat.

Overall, I think it's worth the effort I went through to install it. Hope I find time to write a 'Unite guide for dummies (like me)' some day...

</comment></comment><comment><USER6> [http://bling.github.io/blog/2013/06/02/unite-dot-vim-the- plu...](http://bling.github.io/blog/2013/06/02/unite-dot-vim-the-plugin-you- didnt-know-you-need/)

<comment><USER7> RTFA - this link appears in the first paragraph.

</comment></comment><comment><USER8> It looks like a clone of Helm (previously called Anything) for Emacs:

[https://github.com/emacs-helm/helm](https://github.com/emacs-helm/helm)</comment>


LinkedIn now serving US and EU traffic by default over HTTPS - <AUTHOR> http://engineering.linkedin.com/https/default-https-update

<comment><USER2> LinkedIn.. the most popular spam website in existence. At least this is a good move I guess.</comment>


Ask HN: What's the configuration of your development machine? - <AUTHOR> Do you use laptop or desktop machine? What's the hardware configuration? Which OS?<p>I'm planning to buy a new one for me. So, wondering what the HN Community is using. <comment><USER2> I use a 13" macbook air with 4gb of ram. When I'm at home, I hook it up to a Dell 30" lcd with an old school MS Natural Keyboard and an Evoluent Vertical Mouse.

<comment><USER3> 13" macbook air with 4gb ram...no extra monitor/keyboar/mouse.

I have a dual 27" screen 8 core, 8gb PC 2.5 feet from me which is great at collecting dust.

</comment></comment><comment><USER4> Thinkpad T410s running Arch and Gnome 3. Switched over from a 3-monitor desktop setup a couple of months back and haven't really looked back. I'm finding it easier to enter "flow" on a 14" screen than with 4000 square pixels of peripheral noise, and it's nice not feeling chained down to one particular location.

If you're not an OSX fanatic, most of the Thinkpads are great machines to hack on.

<comment><USER5> Also running a T410, + Ubuntu and Gnome 2. Works for me (mostly Python and a bit of C).

</comment></comment><comment><USER6> 13" MackBook Pro (2011 Core i7) with 4 GB RAM using an external Acer 24" lcd and a fancy logitech mouse. Please find another brand for the external monitor, Acer does not have drivers for mac :s

</comment><comment><USER7> \- 15" MacBook Pro (2010 Core i5) with 8GB RAM. Swapped out the stock HD for a 120GB SSD and used OWC DataDoubler to put in a 1 TB 7200 RPM hard drive for media/scratch.

\- 27" Apple Cinema Display.

\- OS X Lion

</comment><comment><USER8> 13" MacBook Pro (2011 Core i7) with 8GB RAM.</comment>


I'm broke entrepreneur so I built service for other broke entrepreneurs - <AUTHOR> Each week I send a list of 5 to 10 business apps & software from whom I've managed to get my newsletter subscribers an extended free trial period. Generally the trial is 2x longer and it's free to join my mailing list.<p>If you a have an app or software suggestion that you think others might love, please let me know in the comments and I'll try to reach out to them. Feedback is also much appreciated. <comment><USER2> Good Incentive. Where can I find the mailing list link?

<comment><AUTHOR> You can signup here: [https://www.gurusama.com](https://www.gurusama.com)</comment></comment>


What if copyright infringement were made completely impossible? - <AUTHOR> http://www.marco.org/287081391

<comment><USER2> Short summery of his conclusion: People would use permissively licensed content and commercial content publishers would die if they wouldn't adopt.

Well, I wouldn't be bet on that.

Maybe, the author of this piece would do so, and maybe quite a few others. But some would switch to something completely different while the majority would simply pay for the content -- just like they did before it was possible to make illegal copies.

Free (whether in beer or speech) is not the only criterion for making buying decisions.

<comment><USER3> Absolutely agreed. I wrote a series of posts regarding Capitol Records's suing Vimeo yesterday that says something similar. ([http://marinich.tumblr.com/post/286389590/vimeo-sued-by- capi...](http://marinich.tumblr.com/post/286389590/vimeo-sued-by-capitol- records-over-lip-dubs) and [http://marinich.tumblr.com/post/286413219/amanda- lyn-ferri-s...](http://marinich.tumblr.com/post/286413219/amanda-lyn-ferri- star-of-the-original-lip-sync))

It's not even that people are sheep who're getting screwed over by record companies. It's that, much as we may dislike them, record companies are providing quite a lot of value, and they're doing their best to preserve the value of the content they're providing, however flawed their approach may be. While I don't think they're doing a service to musicians, the strategy espoused here and by others — make music valueless and profit by other methods — doesn't sit well with me at all. Even if it _is_ inevitable, and I'm still not _entirely_ certain that it is, I think it would be a great loss if people started seeing music as intrinsically worthless.

<comment><USER4> I view music as worthless. I don't download music off the net or listen to the radio and I have never payed for music. If music cost a million dollars a song or zero it would have no effect on my life at all.

So where is the loss? Do I miss out on bad poetry or meaningless instrumentals? Simple patterns of sound? What?

PS: No I am not deaf, I just find music to be boring.

<comment><USER5> That's funny, I feel that exact same way. No one has ever understood this view point. I'm glad to know there's another like me out there. I always figured it was just me.

I can appreciate music sometimes but I just can't imagine sitting down to listen to music as a pastime... or paying for it.

<comment><USER3> Can you imagine people reading as a pastime? Or watching movies? Or watching sports?

Music is a technical display wherein people each create something and, woven together, it becomes a song. You can't imagine being riveted by five instruments each weaving around one another, by the various techniques each one employs, by the editing process required to create each sound? It's just like watching fourteen people run a ball around on a field, but the movements are planned ahead of time and the execution is key.

Maybe it's not your thing, but I'd hope you can at least understand the appeal to other people.

</comment></comment></comment></comment></comment><comment><USER6> _(I know this isn't possible, but bear with me. It's a "thought experiment".)_

Theorizing too much about the impossible is a risky activity, like deliberately practicing bad rhythm. You can train your mind to fall into patterns of misguided thought. You can wind up being deathly afraid of shadows that do not exist. Abstraction can be good for a while, like training wheels on a bicycle, but try to respect the limits of your abstractions and spend a healthy amount of your time in the real world.

I don't remember which lawyer -- might have been Lessig, might have been Moglen -- made the obvious point that copyright law can't be adjudicated by computer. Here are fifteen words taken from a copyrighted work:

 _In the beginning the Universe was created. This has made a lot of people very angry and has been widely regarded as a bad move._

A computer can detect that these words are from a copyrighted work and censor them. But it can't figure out that in this context -- a brief educational example as part of an essay -- my use of these words is obviously a case of fair use. That's for a judge to decide. Judges are not run by algorithms that we know how to duplicate.

If quotations that matched previously copyrighted work were literally "completely impossible" human thought would grind to a halt. Just read the Spider Robinson short story, which will tell you everything you need to know about this counterfactual, and then worry about something more subtle but actually real, like the problem of corrupt judges, or selective enforcement of unrealistic laws, or the fact that fair use could end up being so expensive to defend that only rich people can exercise it without fear.

</comment><comment><USER7> I find it strange that copyright law is becoming more and more restrictive. Before the Internet it was a lot harder to violate copyright laws and also one had far less legitimate reasons to do so. I mean 10-15 years ago no one cared about old movies still having copyright, because there was no way to distribute or watch them in an effective way. Also there are "markets" today where it's virtually impossible to violate copyright, one being playstation 3 games.

<comment><USER8> It was still an issue. It just didn't affect the average person quite so much.

The industry still hated vcrs, xerox machines, libraries, radio, mix tapes, etc. They still sued any time they could.

It was just impossible for them to identify the people copying cassettes, taping concerts, swapping mix tapes, xeroxing a passage from a book, etc. And when they did try to sue libraries to, say, try to block their lending VHS tapes, the average person didn't take much notice.

<comment><USER4> They also lost a lot of important cases back then.

</comment></comment></comment><comment><USER9> This has been thought about for quite some time: see <http://en.wikipedia.org/wiki/Project_Xanadu>

</comment><comment><USER10> The gist of this article seems to be that some copyright infringement is fine and should be tolerated. Does this view hold for the GPL?

<comment><USER11> Indeed, some copyright infringement IS fine: casual whistling of a tune, quoting passages of books for reviews, copying the cut and fit of stylish trousers, things like that.

Since copyright is enforced by the state, for the purposes of advancement of art and science, we have to draw a balance. "Copyright" isn't state-policed money to be given to an "artist" and his/her/its heirs for ever. Copyright is supposed to entice people to create more stuff, by allowing a small monopoly.

If and when that monopoly becomes too costly to society, the state gets to revoke it. Like it or hate it, the GPL doesn't really have that kind of cost to society. GPL'ed code is open for people to build on, to create with.

Beyond that, "GPL" is a license, not a copyright. Actions against entities under the GPL are not really "copyright" suits, as I understand it, but rather contract suits.

To sum up: you're hoping that people forget what purpose copyright has, and you're hoping that people don't understand the difference between "copyright" and "license".

<comment><AUTHOR> No, the GPL2 is a conditional copyright grant agreeing to waive some of the standard "All Rights Reserved" terms provided that you meet its copyleft terms.

It's not a contract, and hasn't been enforced that way -- _all GPL2 violations are copyright infringement_ \-- you're distributing someone else's work without their permission.

This is also why the AGPL is unenforceable bullshit (it attempts to restrain your right to run the software, not just distribution), and why the GPL3 is extremely questionable (restraining the system on which you distribute the work).

<comment><USER11> You know what? You're correct: GPL suits have been copyright suits - but only because the terms of the LICENSE have been violated. Apparently the SFLC (main GPL litigator) hasn't done any of their suits under contract law. Perhaps the overly strict (a.k.a. "draconian") copyright regime we suffer under allows them to more easily win, or at least threaten for more damages.

However, GPL _is_ a license, and it does waive some of the "rights" that usually get claimed, as long as you observe the terms of the license. In that respect, it's identical to EULA's.

But the GPL doesn't do the "it's mine, all mine, my precious" sort of hoarding that the usual licensing does, so I doubt that we'd ever see anyone busting copyright because the GPL is used to create artifical scarities, or jury-rig markets or the other stuff Big Media does with "all right reserved" copyright.

<comment><AUTHOR> The GPL2 is less restrictive than any EULA I've seen -- it only addresses distribution, and only restricts things that standard "All Rights Reserved" copyright would restrict anyway. It's purely a copyright license, and I respect it for that, even if morons paste it into the "I accept" textarea in their installer-builders.

The AGPL, _now that's a EULA_. It hits the trifecta of basic wrongheadedness, poor implementation, and total unenforceability. The only thing it's missing is the admonition against using it in a Nuclear facility or exporting it to Libya.</comment></comment></comment></comment></comment>


MenuetOS: Written in Assembly, fits on a floppy, has GUI - <AUTHOR> http://www.menuetos.net/ <comment><AUTHOR> An interview with two of the developers:

[http://www.goodgearguide.com.au/article/315421/we_talk_devel...](http://www.goodgearguide.com.au/article/315421/we_talk_developers_behind_menuetos_an_operating_system_written_entirely_assembly_language?pp=1)

</comment><comment><USER2> <http://en.wikipedia.org/wiki/KolibriOS> deserves a mention too, GPL fork of MenuetOS.

</comment><comment><USER3> That's not just a GUI -- it looks like it supports alpha transparency. That's certainly more than I expected out of a floppy disk.

<comment><USER4> Adding alpha transparency for a framebuffer based GUI need not take more than a few hundred bytes.

<comment><USER3> A few hundred bytes is precious space on a floppy.

</comment></comment></comment><comment><USER5> Interesting and impressive.

The 64 bit floppy image runs fine under VirtualBox if you select a 64 bit OS.

<comment><USER6> Virtual Box? It's great that people can try it out and see what it's capable of, but doesn't that sort of defeat the point? I mean, if its real claim to fame is that it's written in assembler than it seems that running it inside a C (is VB C?) application on top of a C operating system would seem to miss its best qualities.

Now if I could only find a floppy around here...

<comment><USER5> Well if you want to try it out for a few minutes, as I guess most people on here will, it beats rebooting your PC (or figuring out how to even make it boot on a MacBook). It's not like it's full featured enough for daily use anyway.

I can't really see your point to be honest.

</comment></comment></comment><comment><USER7> What's a floppy?

<comment><USER8> Something that's not to be copied, IIRC.

<comment><USER9> D-D-Do-Do-Don't...Don't copy.. Don't copy that floppy!

<comment><USER8> Linkage: <http://www.youtube.com/watch?v=XWf_jbrpn4o>

</comment></comment></comment></comment><comment><USER10> I have to admit, that's some of the friendliest looking assembly source code I've seen. <http://www.menuetos.net/e64.asm> Granted, I haven't looked at assembly in over 15 years...

<comment><USER11> Decent -- nothing special (if you consider decent as being good code written by smart people). FASM was an interesting choice and I'd like to see their justification for that.

</comment></comment><comment><USER2> I think this kind of projects are good reminders that modern computers have incredible amounts of processing power and storage capacity. If only all that power could be harnessed efficiently....

I also think that legacy cruft is hindering development in computers. One reason why (GNU/)Linux was able to advance so quickly was that it had much less legacy than other systems, allowing more freedom for developers to do stuff better way.

</comment><comment><USER12> Reading the changelog belies the complexity of that project... I would dearly love to have the time to take a look at the code for it.

Well done!

<comment><USER13> Is this _belie_ definition 2, "To tell lies about, esp. to calumniate by false statements", definition 4, "To give a false representation or account of, to misrepresent; to present in a false character", definition 6, "To call (a thing) false practically, to treat it as false by speaking or acting at variance with it; to be false or faithless to", or definition 7, "To show to be false, prove false or mistaken; to falsify (expectations, etc.)"? I don't see how any of those makes sense, given that it's an _action_ by some _person_ being said to belie an _attribute_ of something. (Maybe that would make sense if you were one of the developers and reading the changelog demonstrated that the project's complexity were somehow "false"?)

(OED 1ed. vol. 1 p.782, 806 of 1270 in the PDF)

<comment><USER14> "belie" can also just mean "to be in contradiction with".

Which I assume was the definition being used. As in, "the simplicity of the changelog is in contradiction with the actual complexity of the project".

<comment><USER15> In that case, definition 4 should fit the bill. Reading the changelog gives a "false representation" on the complexity of the project.

</comment></comment></comment></comment><comment><USER16> I would rather see a hand-optimized version of L4, packaged with a kernel for Debian.

Or an OS written in Forth.

<comment><USER17> "ForthOS is a complete, standalone operating system for the PC. It includes command line, compiler, debugger, editor, and filesystem."

<http://www.forthos.org/>

<comment><USER18> Implement a Forth on the OS. If the rest of the OS is in ASM anyway, you can do high-level work in Forth.

</comment></comment></comment><comment><USER19> I remember similar projects many years ago: \- QNX \- SqueakOS \- SqueakNOS

<comment><USER13> Linux, ColorForth, GEM, Kontiki, Oberon, the Macintosh System, Microsoft Standalone BASIC, Microsoft Windows, etcetcetc.

</comment></comment><comment><USER20> Amazing. The hardest part probably was to find a floppy drive to read / write the floppy. I don't think I have installed one on my last 2 rigs.

</comment><comment><USER21> So does having all the labels in UPPERCASE save that much space?

</comment><comment><USER22> Wow it's improved since I tried it about a year ago

</comment><comment><USER18> Which one is more active, KolibriOS or MenuetOS?

</comment><comment><USER23> Cool, but can I run Erlang on it?

</comment><comment><USER24> Seemed like a good idea when they first got it out. It seems now like it was soo long ago.

Maybe it is interesting for embedded devices, but seems they've lost their purpose. It was never meant for business, but again, what's the point?

<comment><USER25> You're reading this on a site called "Hacker News" and you have to ask that? How about: the challenge.

<comment><USER24> There is a difference between a challenge that is of use for this world, and a challenge just because.

I don't see technological, logical, or knowledge progress in the attempt to write complete OS in assembly (anymore). I've done it myself, in high school, just for fun, a 16bit. That is also when MenuetOS came out. Now I spend my time more wisely. I've actually went on doing things that benefit the society the technology and the users.

Not that menuetOS is bad, but I suggest they reorient them selves so that there is that usable part. And I can see space for it, in embedding computing f.i. Far from having no respect for their work, which I have my hands in from day one.

<comment><USER26> So, essentially your point is that because you have already done something others should be spending their time more productive ?

To some the challenge really is all there is. I'm _very_ happy to see some counterculture to the bloatware that is the norm.

This is an amazingly compact and neat hack, it incorporates a very fast and lightweight GUI that can be used for general purpose computers just as easily as for embedded systems.

<comment><USER24> Hmm. I don't think I am making my self very clear. I think it is a great challenge, and I know what it takes to do so.

However, as Novash says - a reason: "that was faster", "couldn't find a good one in this language", "friendly enough", that seems to be missing. It was there long time ago when they started (for those of you who remember), but today everything shifted. I don't go building theories anymore on the statement that the world is flat?

So stop attacking me because I gave an opposing opinion and suggestion for improvement. It is great what they do, but I am sure like any other programmer, they too would like their code and idea used, not forgotten.

This was not about productivity or stupidity of projects, so reread my comments before you burst. I also do stuff all the time just to see if it can be done. Don't all of us? But again, "if it can be done" solves a problem. Redoing _same_ things just because, now that's something worth discussing.

<comment><USER26> ok I get it now. Sorry for the misunderstanding!</comment></comment></comment></comment></comment></comment>


Evolution of Positioning Techniques in Cellular Networks, from 2G to 4G (2017) - <AUTHOR> https://www.hindawi.com/journals/wcmc/2017/2315036/ <comment><USER2> Not a question related to the post, but a curiosity nonetheless.

Is Hindawi a reputable publication?

They are all about open access and many of their pubs appear interesting to me, but honestly I don't know what experts opine of this particlar journal. Read Hindawi papers a lot as part of my UG research.

</comment><comment><USER3> Anything on the roadmap for indoor positioning?

<comment><USER4> Beamforming and mmWave are approaches which could one day be used for indoor positioning.</comment></comment>


Three Russian doctors fall from hospital windows, raising questions - <AUTHOR> https://www.cnn.com/2020/05/04/europe/russia-medical-workers-windows-intl/index.html <comment><USER2> I think because of coronavirus fear.

</comment><comment><USER3> It's CNN, They probably made up the story based on little or no evidence for ratings.</comment>


Open source to shape cloud computing, but not dominate it - <AUTHOR> http://news.cnet.com/8301-13505_3-10278914-16.html?part=rss&subj=news&tag=2547-1_3-0-5

<comment><USER2> I don't understand the author's point. You can't compare a library/system like hadoop to an implementation of that system. Apache Hadoop isn't a business.

</comment><comment><USER3> That article irks me as it makes no sense. First, there in fact is very little room for _commercial_ software in the cloud: the clouds are built using either in-house developed tools, open source software, or combinations thereof.

Second, what people run _on top_ of cloud platforms is almost always open source software: in fact, it would be hard to see open source distributed computing projects such as Hadoop and Voldemort gaining much traction _without_ "the clouds".

Third, there's a whole business model for open source software: the software itself can be released free (as both in speech and in beer), while the customer would be charged for the _service_ of running the software on vendor's premises (the vendor nets a profit, while the customer still as they don't have to build out the hardware infrastructure/perform systems administration/customize the software themselves).

</comment><comment><USER4> Three misc thoughts:

1) To me there seems to be a long distance between "no place for open source" vs "open source will shape but not win..."

2) While it may be so that "the vendors of today are the same vendors of 10 years ago"; that does not hold true when sliding this 10yr window back in time. I certainly don't think its fair to say this will needs hold true in future either. Maybe the best that can be said is that "vendors appear to have time constant of around 10yrs"

3) What's with all this talk of "winning" anyway? Winning implies there is an end / finish line - tech is so transitory I don't know if its possible to say anyone has ever "won" anything, maybe "dominated" for some period of time, but its never really over, is it?

</comment><comment><USER5> yeah, tell amazon to remove all their xen-based services.</comment>


Show HN: Workplace search engine for all of your internal documents - <AUTHOR> https://evertrove.co <comment><USER2> This might be amazing - depending on how you plan to do integrations with different service, indexing and caching. Adding new services should be really easy from both user and developer side (well, depending on the service). How do you plan to do indexing? On the go or when connected? And how do you plan to include authorisation levels?

Also do you plan to cache some documents that are often searched? I assume there's a 20% of documents that's searched 80% of the time in each organisation and part of the 20% rapidly changes (so there's a decline of the 20% with information constantly incoming but for simplicity let's leave it at that).

Is there a possibility you will perform "auto tagging" on documents? (by channels on slack, folders on drive, people involved, project names, basically any meta info that might allow to narrow down the serarch?)

Also, I hope you're gonna have a self-hosted version, since I believe that may be a make-or-break for many orgs.

Besides all this, awesome, you found a dope problem to solve, this might be huge!

<comment><USER3> Wow thanks for the kind words! I'm one of the makers. We still haven't found a solution for some of the problems that you've mentioned, but our focus from the start will be around privacy. I think you've grasped that problem yourself when you mentioned a self-hosted version.

On the technical side, we currently see this as something that can index on- the-fly, and maintain an internal representation of all the people who have the authorization needed to see the document.

I really like the idea of "auto-tagging". There's already research done on algorithms that generate tags from bodies of text. So it shouldn't be too difficult to integrate that into indexing.</comment></comment>


AWS CodeArtifact: A fully managed software artifact repository service - <AUTHOR> https://aws.amazon.com/about-aws/whats-new/2020/06/introducing-aws-codeartifact-a-fully-managed-software-artifact-repository-service/ <comment><USER2> This has been a fairly obvious service that has been missing for a while, nice to see them provide a solution.

Most dependency management tools have some kind of hacky support for using S3 directly.

Full fledged artifact management tools like Artifactory and Nexus support S3 backed storage.

Interesting to see that the pricing is approximately double that of S3, for what I imagine is not much more than a thin layer on top of it.

<comment><USER3> Considering the price of Nexus and Artifactory this is way cheaper for a SAAS offering with SLA's. I imagine Artifactory is really going to have to up their product offering or at least lower their entry prices.

<comment><USER4> Github already released their package repo last year (and have since purchased NPM). If anything I imagine that had Artifactory pretty scared vs. this. If your company already uses GitHub it's a hard sell to say why you'd need something like Artifactory over the Github package repo.

<comment><USER5> And since I've been trying GitHub Actions, I don't know why you would need artifactory, nexus or this aws service anymore. Github offers private repositories, releases, project pages, cicd through actions and Microsoft is offering plenty of deployment options on Azure with AKS or plain Azure Compute

<comment><USER6> [https://twitter.com/pahudnet/status/1271141814389493760](https://twitter.com/pahudnet/status/1271141814389493760)

</comment></comment></comment></comment></comment><comment><USER7> The login credentials expire after 12 hours (or less)[1], just like with their Docker registry (ECR). That makes it pretty annoying to use, especially on developer laptops.

GCP has a similar offering[2]. And GitHub[3].

[1] [https://docs.aws.amazon.com/codeartifact/latest/ug/python- co...](https://docs.aws.amazon.com/codeartifact/latest/ug/python- configure.html)

[2] [https://cloud.google.com/artifact- registry](https://cloud.google.com/artifact-registry)

[3] [https://github.com/features/packages](https://github.com/features/packages)

<comment><USER8> I could not disagree more re. the expiring credentials. It is a bad practice to have credentials that never expire, especially on developer laptops, especially credentials of this nature. Developers frequently store this stuff in plain text in their home directory or as environment variables. That's a huge security risk! This service manages the process of generating and expiring credentials automatically, which is awesome.

<comment><USER7> This service is for code artifacts. What credential to the developers use to access source code? Do they expire?

It is common for developers to use Git to store source code, in a hosted service like GitHub. It is common to use SSH keys to access Git. Frequently those SSH keys are generated without passphrases. Those are non-expiring credentials stored on disk. If HTTPS is used to access Git, it will likely be with non-expiring credentials.

I'm not saying short lived credential are bad, not at all. I'm pointing out how this service differs from similar services, requiring a change it workflow, which might be annoying to some people. Not everyone is operating under the same threat model.

<comment><USER9> Your source code may reference a shared library at a specific version from a trusted source to build. This trusted source is CodeArtifact.

The short lived passwords is a non issue and a good thing. Your dependency resolver should handle fetching the new password and most orgs I've worked at had scripts dealing with short lived passwords/iam.

<comment><USER7> > Your dependency resolver should handle fetching the new password

According to AWS's documentation, none of the supported dependency resolvers will fetch the new password[1][2][3].

If they were capable of automatically fetching the new password without human intervention, it would mean they have credentials for generating credentials. If this isn't on an EC2 instance (where an IAM role can be used), that means there are long-lived credentials (probably written to disk) used to generate short-lived credentials.

This would be the case if you are using a hosted CI service that doesn't run on your own EC2 instances. You would probably be providing an AWS key and secret, which would then be used to generate the short-lived credentials. But the key and secret won't be short-lived, and will have at least the same access as the short-lived credentials (probably more access).

> Your source code may reference a shared library at a specific version from a > trusted source to build. This trusted source is CodeArtifact.

HTTPS is what forms the trust between you and the artifact repository. Short- lived passwords don't do anything to ensure you are talking to the real trusted source. They may make it so the artifact repository can better trust you are who you say you are, but I don't see what they has to do with safely getting a specific version of a library.

[1] [https://docs.aws.amazon.com/codeartifact/latest/ug/python- co...](https://docs.aws.amazon.com/codeartifact/latest/ug/python- configure.html)

[2] [https://docs.aws.amazon.com/codeartifact/latest/ug/npm- auth....](https://docs.aws.amazon.com/codeartifact/latest/ug/npm-auth.html)

[3] [https://docs.aws.amazon.com/codeartifact/latest/ug/env- var.h...](https://docs.aws.amazon.com/codeartifact/latest/ug/env-var.html)

<comment><USER10> > that means there are long-lived credentials (probably written to disk) used > to generate short-lived credentials.

In terms of local development experience, most mature organizations will have these "long lived" credentials still require an MFA at a minimum of once per day and locked down to particular IP addresses to be allowed to get the temporary credentials.[1]

> This would be the case if you are using a hosted CI service that doesn't run > on your own EC2 instances.

Typically you'd want to see third-party platforms leveraging IAM cross-account roles these days to fix the problem of them having static credentials. Granted, many of them are still using AWS access key and secret.

This is still not a "solved" area though, and a point of concern I wish would get more aggressively addressed by AWS.

[1] [https://github.com/trek10inc/awsume](https://github.com/trek10inc/awsume), [https://github.com/99designs/aws-vault](https://github.com/99designs/aws- vault), and a few other tools make this much easier to deal with locally.

</comment></comment></comment></comment></comment></comment><comment><USER11> Is it just me or is this missing plain artifacts - those that are not packaged for a specific tool? I'm thinking of plain binaries and resources required for things like db build tools and automated testing tools - just files really. How do I publish a tarball up to this, for example?

Also the lack of nuget is a major issue.

<comment><USER12> I think CodeArtifact loses value when you aren't using a package manager; the benefit is an api-compatible service with various controls and audits built on top.

Out of curiosity, what would you want from this service for the "plain binary" use-case when S3 already exists?

<comment><USER13> It's nice having the metadata around the push available versus raw blobs to s3.

<comment><USER14> Objects in S3 can have custom metadata associated with them. Look at the returned data for the HeadObject call.[0]

It's not advertised in the documentation, but HeadObject(Bucket, Key)['Metadata'] is a neat dictionary of custom values.

0: [https://docs.aws.amazon.com/AmazonS3/latest/API/API_HeadObje...](https://docs.aws.amazon.com/AmazonS3/latest/API/API_HeadObject.html)

</comment></comment></comment></comment><comment><USER15> It's frustrating to not see more system package management (deb, rpm) from these new services (github and gitlab for instance).

Are others not packaging their code in intermediate packages before packing them into containers?

<comment><USER16> What's the purpose of intermediate packages if you're already using containers?

<comment><USER15> Very large c++/python/cuda application that is packed into various different images (squashfs images, but functionally the same).

We end up having a lot of libraries that are shared across multiple images.

<comment><USER16> Would it not be easier to just pack into different base images? Docker is very efficient with reusing these layers.

</comment></comment></comment></comment><comment><USER17> I'd like really like to see more support added (Ruby, etc). It could be a great alternative to Artifactory.

</comment><comment><USER18> No C#/Nuget support? Really?

<comment><USER19> AWS products always take an MVP approach. The rest is driven by customer feedback on the roadmap. CodeGuru/CodeProfiler/X-Ray are similar to limited language support they've built out over time.

Whenever I see a product announcement like this missing something I need to use it, I immediately ping our Technical Account Manager to get the vote up for a particular enhancement.

<comment><USER20> sounds surprisingly manual. has AWS not tried to formalize some sort of feature voting system?

<comment><USER19> Some products have started doing public github "roadmaps". Use github issues to get more accessible public feedback but who knows how that gets processed internally.

</comment></comment></comment></comment><comment><USER21> You know it's an AWS service when you look at it and go "Huh, it's only 2x the price of S3, what a bargain!"

<comment><USER22> 2x the price of S3 is very cheap.

</comment></comment><comment><USER23> No deb, RPM, or nuget. Half a product really. As annoying and expensive as Nexus and Artifactory are, at least they're more fully featured.

</comment><comment><USER24> Seems like a direct competitor for Artifactory and Nexus. I wonder if it is profitable for them to create an inferior alternative to fully flagged artifact managers. Or if they are doing this for product-completeness of AWS.

</comment><comment><USER25> I'd wait a few years to be ready, AWS developer tools are really crude. Last year I had to build a Lambda to be able to spit multiple output artifacts in CodePipeline.

</comment><comment><USER26> Appears to support ivy/gradle/maven, npm/yarn, and pip/twine only.

</comment><comment><USER27> What is wrong with S3?

</comment><comment><USER28> I don't get it.

The git server you use supports artifacts already. You could also just put all of your artifacts on an S3 bucket if you needed somewhere to put them, which is exactly what this is but more expensive. I don't understand when this would save you money or simplify devops.

<comment><USER29> It's not "exactly what this is". Every time AWS or Azure or GCP releases a service, there are a droves of people on HN decrying them as "just <something I'm familiar with>", without bothering to understand if that's actually true. It's not.

Skim the docs and you will see it is not "just S3".

<comment><USER30> yep. I've worked on a solution that "just uses s3". It is not trivial.</comment></comment></comment>


John Wilmot, Earl of Rochester – The Wild Man of the Restoration (2014) - <AUTHOR> https://www.theguardian.com/books/2014/jul/20/blazing-star-life-times-john-wilmot-earl-rochester-review-wild-man-restoration <comment><USER2> I read this one years ago, said of King Charles II:

We have a pretty witty king, Whose word no man relies on, He never said a foolish thing, And never did a wise one.

Charles is reported to have said it was true, because his words were his own, but his actions were those of his ministers.

</comment><comment><USER3> Many pages of poetry that would get a trigger warning today, but a handful of very good poems.</comment>


What Netflix bought from Comcast is a CDN - <AUTHOR> http://clipperhouse.com/2014/05/07/what-netflix-bought-from-comcast-is-a-cdn/

<comment><USER2> A CDN serves content from its own servers, so I wouldn't say that Netflix is buying CDN service from Comcast. It's paid peering.</comment>


"The biggest challenge is working on a globally dispersed team." - <AUTHOR> https://www.bugtrackers.io/interview-infragistics-rani-angel

<comment><USER2> Seriously?! "Do the needful" (as Infragistics managers like to say) to make it work for you :)</comment>


Describing and Inventing a New Regular Expression Quantifier - <AUTHOR> https://blog.robertelder.org/regular-expression-quantifiers/ <comment><USER2> From the article:

> I will suggest, rather opinionatedly, that possessive quantifiers aren't > particularly useful.

I will suggest the opposite, that possessive quantifiers are so useful they should have been the default, as backtracking causes problems of performance and accidental mismatching that you usually don't want.

Backtracking is a really useful invention. But it should not be used on every term.

I default to using possessives more often than not these days. I've writte a lot of parsers over the years where regexes played a role, and this is what I found in practice.

Now, a non-possessive quantifier makes me stop and think if it should be there, and what kind of problem is it hiding. Usually it doesn't matter, especially when the regex is being used on "known" data, but occasionally it's hiding a subtle parsing bug.

For example, any regex that is matching whitespace-separated terms. For the whitespace, which makes more sense, "\s+" or "\s++"?

The latter. Backtracking over whitespace is just a waste of time; it won't change what is matched, and if it does, that's usually a bug in the rest of the regex.

What about matching words in a parser of a typical programming language, does it make more sense to write "\w+" or "\w++"? The latter again. You do not want to accidentally treat "iffy" as though it's an "if" followed by "fy".

You can explicitly require a word boundary or a non-word character after the word. But which is more straightforward (and faster) out of "\w++", "\w+\b" and "\w+(?:\W|$)"?

</comment><comment><USER3> Note: the author is not describing regular expressions (ie those that correspond to regular languages and nothing else), but seems to be describing some mixed beast. See eg their mention of backtracking, which is an implementation technique used in some implementations of regular expressions (where it adds nothing); and also in many implementations of not-quite- regular-expressions, where it can make a real difference.

<comment><USER4> Unix style regular expressions is what most programmers mean by regular expressions ("regular expressions" have been non-regular long before perl, fyi. Even old style unix "basic" regular expressions are irregular and i think they go back to the 80s), and is much more common than the concept in language theory that they are named after. I think its pretty obvious from context the author is talking about the common concept and not the obscure concept.

<comment><USER5> I think (perhaps incorrectly) that posix regular expressions can be converted to finite state machines (and in fact, that is how you make them run efficiently), it is the PCRE that cannot be fully converted to finite state machines. (but willing to be corrected on this!)

<comment><USER4> /^\\(.*\\)\1$/

(Match all lines that are palidromes in posix BRE syntax) cannot be done with a finite state machine.

<comment><USER6> That will match 'abab' for example but a palindrome is not that, it reads the same forward as backward, so 'abba' is a palindrome but your rex won't match it.

I don't think a state machine can do it as it needs to remember the captured part, but not sure. Fairly sure capture groups can't be FSMs.

<comment><USER7> The language of palindroms over a finite alphabet is described by a deterministic context-free grammar, you need a pushdown automaton (i.e. a finite state machine with a stack) to recognize it.

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

<comment><USER3> To be more precise, you'd need to say that the palindrome is not only described by a deterministic context-free grammar, but that it is _not_ described by anything simpler.

Multiple different grammars can define the same language. There are context free grammars for regular languages.

<comment><USER6> Ah, now that makes more sense! Original comment threw me rather. Thanks.

A -> bAb where b is a terminal, ok.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> Yeah, the possessive quantifier looks like that it simply disables backtracking but it also silently makes the matching greedy. It should really have been orthogonal: `a+` is greedy and backtrackable, `a+?` is non-greedy and backtrackable, `a++` is greedy and atomic, and `a+?+` is non-greedy and atomic. It's not pretty, but multiple quantifiers were never pretty after all.

Or better, ditch the opportunistic use of otherwise invalid quantifier sequences and stick to the atomic group. Vim got this almost correct [1]:

                  multi ~
             'magic' 'nomagic'  matches of the preceding atom ~

        |/\{|   \{n,m}  \{n,m}  n to m          as many as possible
                \{n}    \{n}    n               exactly
                \{n,}   \{n,}   at least n      as many as possible
                \{,m}   \{,m}   0 to m          as many as possible
                \{}     \{}     0 or more       as many as possible (same as *)

        |/\{-|  \{-n,m} \{-n,m} n to m          as few as possible
                \{-n}   \{-n}   n               exactly
                \{-n,}  \{-n,}  at least n      as few as possible
                \{-,m}  \{-,m}  0 to m          as few as possible
                \{-}    \{-}    0 or more       as few as possible

        |/\@>|  \@>     \@>     1, like matching a whole pattern

So a non-greedy and atomic pattern would be `\%(a\\{-}\\)\@>`. Unfortunately you can't write `a\\{-}\@>` and have to wrap `a\\{-}` into a non-capturing group though.

[1] [https://vimhelp.org/pattern.txt.html#pattern- overview](https://vimhelp.org/pattern.txt.html#pattern-overview)

</comment><comment><USER9> This one was pretty cool and new to me. I'm not sure if I would have read it as how it works or as "Any one, but only one, of these, one or more times".

        (cat|dog|bird){1,2}
             will match any of the following strings:

        cat
        dog
        bird
        catcat
        catdog
        catbird
        dogcat
        dogdog
        dogbird
        birdcat
        birddog
        birdbird

Regardless, its pretty neat!

</comment><comment><USER5> Story time about an interview experience I one had.

So I once interviewed at Google (well, I've interviewed at google many times, and have never gotten passed the hiring committee, but my resume looks decent so recruiters keep coming after me)

Anyways, on said interview, I was asked to program a relatively simple regex matcher (characters and star, perhaps ., don't remember).

Anyways, I totally bombed that question (I'm a big believer that 45m isn't enough time to organize ones thoughts on said Q as phrased, as it gives you nothing to build on, but I'll get back to that in a bit). This of course through me off for the rest of the interview day, because I tend to chew on problems that I have trouble with and tend to not let go of them quickly until I have some better understanding of the issue (including perhaps my limitations in being able to do anything about it).

So after the interview, as I tend to do, I did a bit of research, and came across this article of Kernighan

[https://www.cs.princeton.edu/courses/archive/spr09/cos333/be...](https://www.cs.princeton.edu/courses/archive/spr09/cos333/beautiful.html)

which put everything into context beautifully

now, why do I think its a terrible interview Q? Because as Kernighan writes

 _" Rob disappeared into his office, and at least as I remember it now, appeared again in no more than an hour or two with the 30 lines of C code that subsequently appeared in Chapter 9 of TPOP."_

if it would take Rob Pike and hour or 2 to come up with a nice solution, what chance do us mere mortals have in the context of an interview with people staring at us.

With that said, I do think this serves as a basis for a good interview question. Take a simple character by character string matcher as Rob Pike wrote, and ask the interviewee to expand on it, how would they add different functionality to it. 1) could they add '.', 2) could they enable it to match anywhere in the text, 3) could they add anchors, 4) and if really good, could they add star support. You get to see how the interviewee thinks about code, thinks to modify code, and being regex, still provides a good basis for thinking about tests. I hope people I interview find this to be a tractable Q.

Getting back to my story, in order to prove to myself I wasn't an idiot (and to learn some java, I was mostly a C programmer in the linux kernel at the time), I decided to take Rob Pike's approach and try to implement as much of a regex matching engine as I could

which turned into [https://github.com/sjpotter/regex](https://github.com/sjpotter/regex).

then when I needed to improve my Go programming skills (and explore possibly bad ways of doing Go programming), I ported it to [https://github.com/sjpotter/regex-go](https://github.com/sjpotter/regex-go)

now, what's the point of this story in regards to the article? Implementing the quantifiers gave me a better appreciation of how they worked, both greedy and not (and the performance impacts of them, especially with my naive implementation of a matcher).

By following [https://www.regular- expressions.info/reference.html](https://www.regular- expressions.info/reference.html) and adding as much as I could (include backreferences, lookahead/behinds and conditionals) it gave me a much better understanding of the power in regular expressions (at least of the PCRE type, I'm not sure my old discrete structures teacher would be happy calling all of these "regular expressions").

<comment><USER3> If you are interested in 'proper' regular expressions, the approach via derivatives is really neat. See [https://en.wikipedia.org/wiki/Brzozowski_derivative](https://en.wikipedia.org/wiki/Brzozowski_derivative) or [https://www.ccs.neu.edu/home/turon/re- deriv.pdf](https://www.ccs.neu.edu/home/turon/re-deriv.pdf)

As for hiring processes, have a look at linked article and discussion at [https://news.ycombinator.com/item?id=9159557](https://news.ycombinator.com/item?id=9159557)</comment></comment>


Macrophobia - <AUTHOR> http://a-nickels-worth.blogspot.com/2007/08/macrophobia.html

<comment><USER2> With great power comes great responsibility. No, really! That's not just a cliche.

Macros are like guns. See gun ownership debates...

<comment><USER3> Macros don't kill readability, bad coders do.

</comment></comment><comment><USER4> I really don't think macros are much different than any other API. The only difference is that it's an API that affects the language itself, and thus the stakes are higher. If you design the API well, then it makes code _so much_ easier to read than if you didn't use a macro. If you design the API poorly, then it makes it much more difficult to read than if you didn't use a macro.

Thus, I think a lot of it boils down to risk aversion.</comment>


Blog Fight Rules Of Engagement - <AUTHOR> http://techcrunch.com/2011/01/16/blog-fight-rules-of-engagement/ <comment><USER2> The most interesting sentence of all is this: "More recently Engadget editor in chief Joshua Topolsky tried to kill our acquisition by AOL."

<comment><AUTHOR> Do you really believe that? I think MA just wants pageviews. I don't even understand the animosity. Engadget covers gadgets, TC covers start-ups and trends. It doesn't seem like they have much overlap.

MA's article accused Engadget of trolling TC's comments, twice in the article, but never once cites any examples then criticizes them for using anonymous sources. A bit hypocritical.

Honestly, at least on Engadget they never stoop this low and resort to MA's tactics for hits/pageviews. Maybe MA just wants to get fired so he can get paid for not working.</comment></comment>


"Failure to report a crime" - <AUTHOR> https://meduza.io/en/feature/2016/06/24/russia-s-state-duma-just-approved-some-of-the-most-repressive-laws-in-post-soviet-history <comment><USER2> There is a great deal wrong with the US. But let us not forget that things are much, much worse in Putin's Russia.</comment>


GitHub's new text editor leaked on Twitter - <AUTHOR> https://github.com/atom <comment><USER2> I really can't wait for this to be released. I am a little pessimistic about the Vim mode. There are countless 80 or 90% complete Vim modes in various modern editors. But the absence of a truly native feeling Vim (that last 10%) is a deal breaker for many. I'd rather see more editor developers spend time finding a solution that provides a _truly_ authentic Vim mode instead of spending countless hours merely approaching 90% compatibility. For the people who you're selling on that Vim mode (the people who would care that your editor provides it) 90% isn't good enough. There are other ways to integrate Vim modes in your editor such as using the (inappropriately named) "Netbeans interface" which actually allows Vim to run in the background while you integrate your UI on top of it across a serializable bridge. This allows a perfect recreation of Vim while letting you customize the application experience on top of it.

Aside from that approach, there are a few faithful Vim recreations that I've discovered out of the dozens that I've tried.

[https://github.com/vicoapp/vico](https://github.com/vicoapp/vico) (Excellent project) [http://www.viemu.com/](http://www.viemu.com/) (Solid experience in Visual Studio) [https://github.com/guillermooo/Vintageous](https://github.com/guillermooo/Vintageous) (fairly close and getting better every day)

But I don't mean to sound like such a pessimist. The progress so far looks excellent and I can't wait to try it out. Keep it up!

Edit: I also notice that the logo looks like an iOS7 version of React's logo: [http://facebook.github.io/react/](http://facebook.github.io/react/)

<comment><USER3> Curious as to your opinion on Evil from Emacs - I've been learning Evil without knowing Vim first, so I don't know what I might be missing.

<comment><USER4> I've used Evil in Emacs with [http://orgmode.org/](http://orgmode.org/), after having learned Vim. I'd say Evil is another great, thorough emulation of Vim. It includes even relatively-obscure features like visual block mode, R, K, v_o, :%!sort, ^W window split/switch/close commands, and Vim's tree undo model.

My only problems with Evil are where Emacs or Emacs plugins' bindings conflict with Vim bindings, such as v_^G (that is, Ctrl-G in Visual mode) meaning "Quit" instead of "Switch to Select Mode". Those conflicts aren't really Evil's fault – they're inevitable when combining third-party plugins that don't explicitly support Evil – but they can be annoying.

I'd say you're not missing much with Evil that would be in Vim. I suppose you're mainly missing Vim's large ecosystem of plugins that are made to work with Vim keybindings and Vim's editing model – though I see that surround.vim has been ported ([https://github.com/timcharper/evil- surround](https://github.com/timcharper/evil-surround)). Plus Vim wouldn't have Evil's and Emacs' keyboard conflicts, of course.

<comment><USER2> I recall this most recent emacs effort the best of all the previous attempts (Viper etc). I believe there was one thing I couldn't fix:

When in command mode (such as when you type :e etc), hitting back space stops at the last deletion. In Vim, if you continue pressing backspace, the editor cursor starts moving back (as if you're pressing `h` in normal mode). (Did you figure out how to fix this?)

It's the little things like this that have become ingrained in our muscle memory over the course of more than a decade.

I do agree that emacs' scripting environment is better than Vim Script.

<comment><USER4> I don't understand your backspace problem. In all of the following cases, Vim 7.3 and Emacs 24 with Evil act the same:

In Command-line mode (by typing `:`), when there is text after ':' and before the cursor, typing Backspace deletes one character behind the cursor. In Command-line mode, if there is no text left but ':', it exits Command-line mode, changing to Normal mode. Emacs displays Quit in this case, while Vim just exits silently. If I press Backspace in Normal mode while the cursor in the middle of a line, the cursor moves back one character as if you pressed `h`.

My full Evil config is here: [https://github.com/roryokane/emacs.d/blob/master/init.el#L12...](https://github.com/roryokane/emacs.d/blob/master/init.el#L12-L38). But I don't see anything in it that would change the behavior of Backspace.

I did just notice an inconsistency with Backspace, but it doesn't sound like what you're talking about: if you press Backspace in Normal mode while the cursor is at the leftmost column, the cursor wraps to the previous line in Vim, but stays in the same place in Emacs. The cause of that behavior in Vim is the 'whichwrap' option's value containing "b". Evil has a rough equivalent to that option in evil-cross-lines (a boolean), but I don't know if it has an equivalent that lets you selectively enable wrapping only for Backspace and Space. [https://bitbucket.org/lyro/evil/issue/247/evil-invert- char-s...](https://bitbucket.org/lyro/evil/issue/247/evil-invert-char-should- respect-evil-cross) implies that there was no exact equivalent as of Febraury 2013.

</comment></comment></comment></comment></comment><comment><USER5> There's a bunch of lovely gems scattered through the Atom repos. Some of my favorites from a first quick glance:

Biscotto — A CoffeeScript API documentation generator based on TomDoc notation:

[http://atom.github.io/biscotto/](http://atom.github.io/biscotto/)

React-Coffee — A little glue that makes Facebook's React easy to use from CoffeeScript without having to resort to JSX:

[https://github.com/atom/react-coffee](https://github.com/atom/react-coffee)

SpacePen: A minimalist view library for jQuery, allowing custom methods, super calls, HTML-building, subviews, and easy event binding:

[http://atom.github.io/space-pen/](http://atom.github.io/space-pen/)

... and the best bit about this bonanza is that everything is really quite readable. Keep up the good work, Kevin.

<comment><USER6> I'm confused, why would they be working on React and SpacePen? Don't they do (roughly) the same job?

<comment><USER7> React is defined by its declarative nature (for ease of coding) and virtual DOM (for performance). Not sure if SpacePen does the same, but at a first glance of the documentation I'm not seeing anything along those lines…

</comment></comment></comment><comment><USER8> holy cow this thing has like 70 repositories!

And I found a screenshot... looks very much like sublime text: [https://f.cloud.github.com/assets/1424/1228569/cce6eb26-27a6...](https://f.cloud.github.com/assets/1424/1228569/cce6eb26-27a6-11e3-8675-a6905e50a9a6.png)

edit: based on this[1], it looks like this is a GitHub-aware/integrated text editor that targets _both_ desktop (Mac, at least) _and_ web

[1] [https://gist.github.com/elcuervo/eb68883f233baf5a46c8](https://gist.github.com/elcuervo/eb68883f233baf5a46c8)

<comment><USER9> Some more screenshots

* [https://f.cloud.github.com/assets/671378/2265086/c6897dba-9e...](https://f.cloud.github.com/assets/671378/2265086/c6897dba-9e7b-11e3-945d-551cac610717.png)

* [https://f.cloud.github.com/assets/671378/2265022/bb148a20-9e...](https://f.cloud.github.com/assets/671378/2265022/bb148a20-9e7a-11e3-81c8-bf5965d48183.png)

* [https://f.cloud.github.com/assets/2988/1796891/85e69ff2-6a93...](https://f.cloud.github.com/assets/2988/1796891/85e69ff2-6a93-11e3-89ac-31927f604592.gif) (animated gif)

* [https://f.cloud.github.com/assets/671378/2241795/ba4827d8-9c...](https://f.cloud.github.com/assets/671378/2241795/ba4827d8-9ce4-11e3-93a8-6666ee100917.png)

* [https://f.cloud.github.com/assets/671378/2241819/f8418cb8-9c...](https://f.cloud.github.com/assets/671378/2241819/f8418cb8-9ce5-11e3-87e5-109e965986d0.png)

* [https://f.cloud.github.com/assets/671378/2241519/04791a24-9c...](https://f.cloud.github.com/assets/671378/2241519/04791a24-9cd6-11e3-9a12-164cabe81d58.png)

<comment><USER10> I love the edit markers in the last screenshot. But too skeptical about the performance of a text editor running in webkit. All of my experiences writing text online have been bad. So the jump into using webkit for an entire dev environment fills me with dread.

<comment><USER11> This is already possible using gitgutter in both Vim and ST, and I've never noticed an impact on performance.

<comment><USER12> Indeed, I'm using it in ST and I haven't noticed an impact on performance.

Screenshot: [http://share.qpleple.com/U8eN](http://share.qpleple.com/U8eN)

</comment></comment></comment></comment></comment><comment><USER13> Haha. [https://twitter.com/shit_hn_says/status/278710645644484609](https://twitter.com/shit_hn_says/status/278710645644484609)

<comment> Dorian-Marie This sounds more like the future than having to get an expensive computer and setup a whole environment on it.

</comment></comment><comment><USER14> All of the competition can only be good for us developers. This, ST3, Light Table, Brackets, etc. Bring on the text editor wars!

<comment><USER15> Don't forget IDE family like [http://c9.io/](http://c9.io/)

Edit anywhere just with a browser is a win IMHO. Also easy pairing.

<comment><USER16> c9 is awesome! One thing keeping me though is realtime collaboration in the open source edition. (Gotta self host, flaky internet).

The closest alternative currently is CoVim. :x

<comment><USER17> Check out Codebox.io, another open source web ide. I've been comparing the two from a self-hosted standpoint. c9 definitely has the more polished interface (for instance, the ability to resize any pain), but codebox doesn't seem to limit any features on the self-hosted version. It just seems to work better.

I only got my self-hosted version running last night and couldn't seem to spot a "chat" option (had two different browsers open) but for any file that was open by two people, you got to see who was editing what within the file.

When I was running c9, I couldn't even get the console to display. I found a plethora of issues in their github issue tracker of other people with the same problem, as well as code suggestions to fix it, but virtually no response on any issue from the c9 people.

I reported an issue I was having with codebox on their tracker. First I thought it was a bug, then I found a workaround (set the USER environment variable before starting codebox). I reported that on the issue, suggesting a documentation update, and within an hour, they had committed new code that made the workaround unnecessary.

So for self-hosted, I think codebox has the more stable and actively developed codebase while c9's open-source version is more of an afterthought. But I do admit that c9's hosted service is much nicer than codebox's hosted service.

<comment><USER16> I checked it out (as recently as yesterday, right after my comment), but it is too buggy and featureless for me.

</comment></comment></comment></comment></comment><comment><USER18> [http://blog.atom.io/](http://blog.atom.io/) seems to be WIP, the meta tags are quite revealing :

At GitHub, we're building the text editor we've always wanted: hackable to the core, but approachable on the first day without ever touching a config file. We can't wait to see what you build with it.

</comment><comment><USER19> Pretty crazy! Here are a few interesting plugins in there already:

      - vim-mode
      - fuzzy-finder
      - emmet (aka Zen Coding)
      - solarized-dark-syntax (heh)
      - snippets (check)
      - language-* (check; so many; awesome)
      - timecop (tracking where time is spent in the editor)
      - editor-stats (graph your mouse / keyboard activitiy)
      - ...

</comment><comment><USER20> Am I the only one who finds it hard to believe this has indeed been leaked and is not just a marketing strategy from Github? The repos are not even private.

<comment><USER21> Leak is the wrong term, and it's doubtfully a deliberate marketing move either. More like, "suddenly being noticed because a bunch of GitHubbers followed the @AtomEditor account on Twitter".

Also, despite the plethora of repositories, the actual editor is not available. It could be many of the public repos are public so they can be installed using their Atom Package Manager, which would likely have to jump through hoops if they were private.

<comment><USER22> That's correct, I'm the one who first found the project and I wouldn't call it a "leak". The site is live (domain registered by GH), the twitter account is live, the repo is full, the release is probably imminent.

</comment></comment></comment><comment><USER23> Flattered to see it using marked for the markdown engine. Maybe the world is finally ridding itself of showdown.

<comment><USER24> And rightly so! Marked indeed is a fine 𝗠⬇ parser!

How would you compare your approach to e.g. markdown-js¹, mdown-parse-pegjs², or text.js³ (which are based on PEG parsing)?

I would like to elaborate a bit on the specific differences/benefits between the many MD parsers. (I'm maintaining an inventory of Markdown resources in a repo on Github.⁴)

[¹] [https://github.com/evilstreak/markdown- js](https://github.com/evilstreak/markdown-js) [²] [https://github.com/shamansir/mdown-parse- pegjs](https://github.com/shamansir/mdown-parse-pegjs) [³] [https://github.com/sheremetyev/texts.js](https://github.com/sheremetyev/texts.js) [⁴] [https://github.com/rhythmus/markdown- resources](https://github.com/rhythmus/markdown-resources)

<comment><USER23> Thanks.

Speed was originally marked's top priority. I would say marked's approach takes advantage of the fact that v8 generates _extremely_ fast machine code for regexes. This is just something I discovered through many endless nights of benchmarking the entire markdown test suite.

Using complex regexes for the lexemes seems like a stupid idea to most people, but it allowed me to optimize marked like crazy, so much so that it beat discount(written in c) in benchmark times (It might be a little bit slower now due to the latest features. I decided to ignore speed for a while to focus on features - will get back to optimization eventually).

The downside of all of this: marked loses some extensibility, however, we implement as much extensibility as possible by exposing the token stream and renderer.

Accuracy and sanity quickly became marked's next top priority. There's a certain threshold of accuracy you want in a markdown engine (you don't want it to be too accurate because markdown.pl had a lot of bizarre behavior). That's a different story.

</comment></comment></comment><comment><USER25> FYI [https://atom.io](https://atom.io) is leaking assets. Here is an album of the images found in the css [http://imgur.com/a/KG4MX#0](http://imgur.com/a/KG4MX#0) the css [http://pastebin.com/FgN3g448](http://pastebin.com/FgN3g448) the js [http://pastebin.com/p1nBmGki](http://pastebin.com/p1nBmGki)

<comment><USER26> The most vital one, showing it wants to be hacked at (in a good way): [http://i.imgur.com/XmLcOhB.gif](http://i.imgur.com/XmLcOhB.gif)

Awesomeness.

<comment><USER27> That's just for a welcome dialog.

</comment></comment></comment><comment><USER28> Looks good and all... but I'm interested in the story on how it leaked on Twitter. The link just goes to the Github repo now.

<comment><AUTHOR> This kicked it off: [https://twitter.com/mattetti/status/438494095506280448](https://twitter.com/mattetti/status/438494095506280448)

<comment><USER22> Thanks for the credits :) I'm indeed the person who figured out what GH was working on based on Twitter's notifications letting me know that a bunch of my GitHub friends suddenly followed the atom.io twitter account. From there it was easy to link things together.

</comment></comment></comment><comment><USER29> [https://f.cloud.github.com/assets/1424/1228569/cce6eb26-27a6...](https://f.cloud.github.com/assets/1424/1228569/cce6eb26-27a6-11e3-8675-a6905e50a9a6.png)

"Collaboration is now working (and accepts 2FA logins)."

</comment><comment><USER30> What sets this apart from the other WebKit-based text editors, LightTable and Brackets? In general it seems like there's been an explosion of new text editors with this style since TextMate went into hibernation around 2008. It's great to have options, but there's lots of these TextMate clones now.

<comment><USER26> LightTable is different then most editors by design, in that it tries to reproduce Bret Victor's idea on "the future of programming".

Brackets is really neat, it just attempts to be a good editor, it has some unique features like toggling css inline from an html file for example and other jazz.

So Atom isn't something that's really set apart from webkit-based editor, but I don't think that's what's important here. It's the potential the stack offers us.

There's also not as much competition in this area, but it's sorely needed. I feel vim, emacs, textmate, sublime and most the editors are generally closed source or have huge code bases, and they are hampering the process of innovation by creating walled gardens or creating a barrier to entry. With a editor based on web technologies things really open up a lot.

Think about an editor where you can write a feature, pass the tests, and have a hot reload. No compiling, no closed source or plugin system. Just simple coffeescript/javascript some html and css. And bam, you've rewritten your status bar without effecting work in progress. That's something an editor should give us.

I digress, I'm just excited by this.

<comment><USER4> As a side note, it seems like Vim will get a little better soon in terms of its barrier to modifying it and creating plugins. Someone has started a credible project to create a fork, Neovim, which will be easier to modify and extend: [https://www.bountysource.com/fundraisers/539-neovim-first- it...](https://www.bountysource.com/fundraisers/539-neovim-first-iteration).

</comment></comment></comment><comment><USER31> "Atom is free during the beta period." [https://github.com/atom/welcome/commit/86790ef7cca263ca0943f...](https://github.com/atom/welcome/commit/86790ef7cca263ca0943f64effc771e2339a2754)

<comment><USER16> Seems like they're going the ST route. I'm kinda disappointed Atom won't be open sourced.

<comment><USER32> It could also mean they are going the Cloud 9 route (unlimited free public editing, limited free private projects) for the web version, which would essentialy be the same as their current subscription model, while still open- sourcing the editor itself.

<comment><USER16> Cloud9's open source edition has a few features missing, most notably realtime collaboration.

</comment></comment></comment></comment><comment><USER33> They're on Twitter: [https://twitter.com/AtomEditor](https://twitter.com/AtomEditor) found the link in the Source Code of: [http://blog.atom.io/](http://blog.atom.io/)

It also has the line: "At GitHub, we're building the text editor we've always wanted: hackable to the core, but approachable on the first day without ever touching a config file. We can't wait to see what you build with it."

</comment><comment><USER34> Never thought I'd be excited for a text editor, but damn I can't wait for this to come out.

<comment><USER35> Me too! I'm a big Sublime Text guy, right, but simply put sublime is lacking, especially in UI flexibility and advanced IDE features, like intelligent autocomplete, type checking etc.

If this thing delivers sublime-tier quality code editing in the browser and desktop AND commands a big enough community to allow for even more features (due to being open source), perhaps even IDE tier features... Sign me the fuck up. I'm tired of using closed source crap, patiently waiting for the dev to get off his ass and build more API functionality.

</comment></comment><comment><USER36> It seems that Holman has already used it 5 months ago. [https://github.com/holman/feedback/issues/432](https://github.com/holman/feedback/issues/432)

</comment><comment><USER37> A text editor in a browser? There seems a lot of excitement about it but I can't work out why - can anyone explain? I'm not trying to be argumentative; I really am curious! It's for editing text and there appears to be massive excitement about it....?

<comment><USER38> I for one use my own web-based version control system and project management. If there was a good web-based texteditor that is 100% vim compatible, I could stop switching between a browser and a shell.

<comment><USER37> What sort of stuff do you work on? Do you use a web based editor to modify stuff locally or is it for web based stuff hosted the other side of the world?

I always SSH'd into boxes and edited stuff there if necessary, or had a local copy to work on using "normal" editors and synced it. But now I'm writing C++ so I am blessed with good IDEs so perhaps that is why I am missing the excitement over a text editor?

<comment><USER38> I work on web based stuff on the other side of the world.

I edit code in vim in screen in ssh.

Used many IDEs in the past, but settled on pure vim.

<comment><USER37> Ah I see the draw of an editor in a page then. Now I understand the excitement.

Thanks!

</comment></comment></comment></comment></comment><comment><AUTHOR> whois atom.io =>

Domain : atom.io

Status : Client Updt+Delt Lock

Owner : GitHub Hostmaster

Owner : GitHub, Inc.

Owner : 88 Colin P Kelly Jr St

Owner : San Francisco

Owner : CA

Owner : US

</comment><comment><USER39> Dig the feed URL: [https://github.com/atom.atom](https://github.com/atom.atom)

</comment><comment><USER40> Website now says "SOON". Response from #atom irc channel:

> Would the editor itself be open-source?

> yes

> a non-opensource editor from GitHub would be ludicrous

> seems like the source code will be up today

<comment><USER41> The person who answered you isn't associated with GitHub and has been trolling the channel (and apparently you).

</comment></comment><comment><USER42> top of HN = leak well done = planned? maybe.

<comment><USER43> To be fair, Github wouldn't need to leak anything to get on the top of HN. Just about any thing they post on their blog gets on the front page for at least a few hours.

<comment><USER44> notions of fairness aside, github doesn't need hackernews. in the slightest. for attention, or for anything else...

and i'm fairly sure that paul graham would say that himself.

-bowerbird

</comment></comment></comment><comment><USER45> Lets reinvent everything in javascript no matter how badly...

<comment><USER46> There is freedom of choice. You don't have to use it.

<comment><USER47> Still, he is entitled to his opinion. You don't have to downvote it. :>

<comment><USER46> Sure

</comment></comment></comment></comment><comment><USER48> I saw this. I have a lot of respect for Githubbers and Github but is Node really the language for a text editor? My text editor that's built natively to my OS often struggles, let alone if it's Node. Seems like they're shoehorning the wrong technology.

</comment><comment><USER49> Apparently it collects usage information?

[https://github.com/atom/welcome/pull/7](https://github.com/atom/welcome/pull/7)

Thanks, but no thanks. I don't need my editor sending usage information anywhere.

<comment><USER31> "If you do not want this information reported, disable this package from the Metrics section of the Settings view"

[https://github.com/atom/metrics](https://github.com/atom/metrics)

<comment><USER49> I saw that as well, but opt-out is a crappy default. It should be opt-in.

<comment><USER50> Why do you care?

</comment></comment></comment></comment><comment><USER51> Any ideas if all the code behind the editor will be released as open source?

Edit: To be clear, I am not talking about all the supplementary repositories that are already open source, but rather I am wondering if the core application will be OS.

<comment><USER52> I'm very curious too. This may make or break it for me.

</comment></comment><comment><USER53> Some interesting new info popping up in the repo: [https://github.com/atom/welcome/blob/master/lib/welcome.md](https://github.com/atom/welcome/blob/master/lib/welcome.md) \- they reference it as being "free during the beta period" \- that coupled with a tweet from mojombo yesterday[1] makes it sound like a whole new line of business for them - sounds big!

[1] [https://twitter.com/mojombo/status/438200146791129088](https://twitter.com/mojombo/status/438200146791129088)

</comment><comment><USER54> The way I code (and I'm surprised I seem to be the first person to state this here), is that I can run my class file in Sublime and it automatically runs its unit test within like a second. Instantly, I can know whether I broke anything or whether I satisfied a new assertion successfully without breaking anything else.

Unless this editor can do something similar, this is pretty much useless for any non-html non-css code developer who has already learned that unit test suites are the way, the truth and the life.

</comment><comment><USER55> Looking good and this only helps confirm that web IDE's are going to be the big thing in the next couple of years.

I've been predicting/preaching about this for 2+ years now and been building my own browser code editor in that time ([http://icecoder.net](http://icecoder.net)).

So, CodeAnywhere gets $600k in funding, Adobe is releasing Brackets to the browser soon, GitHub is launching Atom as a web based offering.

Need much more reason to leave the desktop behind?

<comment><USER51> Do any of these support an offline mode?

</comment></comment><comment><USER56> I sure hope this will have a rich plugin API and support non-web non-scripting languages as first class citizens. That would make it stand out from most recent editors.

</comment><comment><USER57> I was excited until I saw it was WebKit based. My confidence level that it won't be slow and buggy is next to zero. I would, of course, love to be wrong.

</comment><comment><USER58> IRC channel here: [http://webchat.freenode.net/?channels=##atom](http://webchat.freenode.net/?channels=##atom)

</comment><comment><USER59> the vim-mode better be really good to make me switch from native vim.

<comment><USER60> The future work section of the readme ([https://github.com/atom/vim- mode#future-work-in-rough-order](https://github.com/atom/vim-mode#future-work- in-rough-order)) lists some really basic stuff, so it's definitely not there yet.

</comment></comment><comment><USER31> [http://whois.domaintools.com/atom.io](http://whois.domaintools.com/atom.io)

      Domain : atom.io
      Status : Client Updt+Delt Lock
      Owner  : GitHub Hostmaster
      Owner  : GitHub, Inc.
      Owner  : 88 Colin P Kelly Jr St
      Owner  : San Francisco
      Owner  : CA
      Owner  : US

</comment><comment><USER61> Glad to see there's an Atom plugin[0] named after the Jean-Claude Van Damme movie _Timecop_ [1]

[0] [https://github.com/atom/timecop](https://github.com/atom/timecop)

[1] [http://en.wikipedia.org/wiki/Timecop](http://en.wikipedia.org/wiki/Timecop)

</comment><comment><USER62> If you go to [https://atom.io/docs](https://atom.io/docs) you can authorize the app with your github account. You still get the 'soon' page afterwards, but at least you're now something like an early atom.io beta user ;)

</comment><comment><USER63> Will this support Linux? I would love to try this on my Linux System. (Ubuntu, to be specific)

<comment><USER64> looks like it is built on node-webkit so probably yes.

<comment><USER65> where did you find that out? just curious

<comment><USER66> package.json everywhere.

</comment></comment></comment></comment><comment><USER16> I like that they are already prepared(/preparing) for Node 0.11, ([https://github.com/atom/node-vm-compatibility- layer](https://github.com/atom/node-vm-compatibility-layer))

</comment><comment><USER56> This looks great! I'd be more than happy with an open source, modern editor to replace the current myriad of specialized-language editors (QtCreator, Brackets, ...), Sublime Text and Komodo Edit I'm using.

</comment><comment><USER67> Atom IRC channel

[https://github.com/atom/welcome/commit/6346bb8c2e7534ae0de5e...](https://github.com/atom/welcome/commit/6346bb8c2e7534ae0de5e9495018f611d99f56f1)

</comment><comment><USER68> [https://github.com/atom/welcome/blob/master/lib/welcome.md](https://github.com/atom/welcome/blob/master/lib/welcome.md)

</comment><comment><USER69> Looks 1000x times better than a project I just started based on Ace.js. Should save me a lot of trouble!

I just hope it's not tightly coupled to the backend so I can replace it with a custom one.

</comment><comment><USER70> Was worth a try...

[https://twitter.com/s10wen/status/438637833981820929](https://twitter.com/s10wen/status/438637833981820929)

</comment><comment><USER71> Looks like this is going to be released today [http://minus.com/i/8HXqEh53LTsB](http://minus.com/i/8HXqEh53LTsB)

</comment><comment><USER72> How is this a leak when THEY HAVE A WEBSITE with a signup form? [http://atom.io](http://atom.io)

:)

</comment><comment><USER73> Very likely that Github bought SublimeText.

<comment><USER74> Why do you say that?

<comment> dav- Atom: [http://i.imgur.com/0Qfwkp4.png](http://i.imgur.com/0Qfwkp4.png)

SublimeText: [http://i.imgur.com/frzYwwc.png](http://i.imgur.com/frzYwwc.png)

Case in point.

<comment><USER75> They look similar. I'd like to be proven wrong and GitHub make Sublime a more maintained and transparent project, but it's doubtful.

<comment><USER76> I think if this kicks out good and will have plenty of plugins sublime will be dead in a matter of months.

</comment></comment></comment></comment></comment><comment><USER77> As the _actual editor_ isn't publicly available in any form, this isn't exactly a "leak".

</comment><comment><USER78> Any word on how to get in on the beta?

<comment><USER79> It sounds like they're preparing to open this to the public. I don't know, though. We'll just have to wait and see.

</comment></comment><comment><USER80> this is very cool. I think many people are underestimating the potential of something like this. There are 1000x as many people who can hack something cool for this than would do so in elisp.

* I'm a happy emacs user but have to admit this is very promising.

</comment><comment><USER81> And I will continue to use an Arch Linux VM, i3, vim, and dwb...

</comment><comment><USER82> It looks like gitblime bought subhub, just kidding. :P

</comment><comment><USER83> the next big thing for devs. I love sublime and will, but can't figure why is it taking them so long, to launch it on mac appstore.

<comment><USER84> Apple's 30% cut

<comment><USER59> Not to mention the amount of features they'd have to remove in order to comply with Apple's standards.

<comment><USER85> Would its plugin / scripting library even be allowed? I don't know the specifics of the OSX app store rules.

<comment><USER86> Based on BBEdit, which _does_ have a version in the App Store, the plugins and scripting would be just fine -- but the CLI integration wouldn't be. (Although you could probably download it separately.)

I don't really see what the advantage of putting ST in the App Store would be, though, for either its developer or any of the users. I like the App Store well enough for certain things, but for developer tools and many utilities the sandboxing tends to be an annoyance at best.

(Also, I don't like that the App Store makes upgrade pricing completely impossible, but that's a whole different rant.)

</comment></comment></comment></comment></comment><comment><USER87> Is this a replacement for gist?

<comment><USER75> No. Gist is a service.

</comment></comment><comment><USER88> Guess, github bought sublime.

<comment><USER75> No.

</comment></comment><comment><USER89> They open beta invites today

</comment><comment><USER90> Looks amazing, but why CoffeeScript?

<comment><USER91> I have the same problem with LightTable... ClojureScript is Lisp and all, but why not Javascript? Huge user base, must be faster since its CS target, and pretty good as a extension language (or just use Lua :))

<comment><USER92> I'll re-phrase an earlier comment: JS is the x86 of the web, so why argue about which macro syntax is superior?

</comment></comment></comment><comment><USER93> If it doesn't come with a vim-mode or that vim-mode is slow and painful to customize, then this will be useless.

<comment><USER75> That's not true.

People like myself who don't use Vim can still navigate code at speed.

<comment><USER16> I think what jbeja meant is "this will be useless for me"</comment></comment></comment>


First Recorded Usage of word "Hacker" - <AUTHOR> http://duartes.org/gustavo/blog/post/first-recorded-usage-of-hacker

<comment><USER2> makes me wonder whether Einstein could safely be called a "hacker" too?</comment>


Physics breakthrough should solve quantum computing's dead cat problem - <AUTHOR> https://thenextweb.com/science/2019/06/03/physics-breakthrough-should-solve-quantum-computings-dead-cat-problem/ <comment><USER2> I'm not going to go through and analyze the undoubtedly dense original research, but if the click-baitey headline is correct, this does seem like a huge jump in our grasp on reality.

From how long have we thought that quantum particle's "leaps" were random, and part of the inherent unpredictability of quantum reality? How long has popular culture around "quantum randomness" been ingrained in our inner imaginations of how the world worked?

This could be the start of something new.

</comment><comment><USER3> Preprint: [https://arxiv.org/abs/1803.00545](https://arxiv.org/abs/1803.00545)</comment>