Given that this site is called "Hacker News", it's worth mentioning that '"useless" programs - pieces of code that serve no practical purpose but are fun, creative, or challenging to write' is one of the central definitions of ”hack”.
I've written some: a programming language interpreter based on Abadi and Cardelli's untyped ς-calculus; a two-kilobyte web server in assembly (which accidentally did turn out to be useful); a self-compiling compiler from a sort of Forth dialect to i386 ELF executables; a translator from standard English orthography to an ASCII alphanumeric phonetic orthography I designed; a one-kilobyte programming language interpreter with dynamic multimethod dispatch and pattern-matching; a base-3 calendar based on the Sierpinski triangle; a C interpreter in Python I used for bytebeat livecoding; several implementations of Tetris, one of which is a 2K ARM executable; an operating system for ARM consisting of five instructions; a few raytracers; a Space Invaders game; a minimal roguelike in Forth; a library for manipulating Boolean functions as Zhegalkin polynomials; many symbolic differentiators; a sort of polyrhythmic drum machine called Pygmusic; a parametric CAD system in PostScript for laser-cutting MDF; 3-D rotating objects in ASCII art in 20 lines of Python; Karplus-Strong string synthesis in one line of C; an audio PLL in one line of C; an RPN calculator with forward-mode automatic differentiation; a slide rule in Tcl/Tk; a port of the logic-programming EDSL μKanren to OCaml; several fractal renderers; a decoder for the "gridfonts" Hofstadter and his research group designed; a Hershey font decoder; several maze generators; a generator for balanced-nonary multiplication tables; a vocoder; a Doom-like first-person raycaster; a teapot mod for the Minetest game; a compiler for a subset of Scheme written in itself; etc.
A lot of this is in http://canonical.org/~kragen/sw/dev3/ which you can clone with Git. I'd be happy to elaborate on any of these if you are interested.
HN's duplicate detector is left weak on purpose so that people can repost interesting things, either because they haven't received significant attention or because more than a year has passed. You may need to change the URL slightly for the repost to work.
Because it's an honor system, we ask people not to abuse this. Examples of abuse are deleting posts that didn't get traction and resubmitting them; or reposts of the same material over and over. In general, we're more tolerant when people are reposting things because they're interesting and less tolerant when they're promoting something.
If a story has had significant attention in the last year or so, we kill reposts as duplicates. If not, a small number of reposts is ok. Please don't delete and repost the same story, though. Accounts that do that eventually lose submission privileges.
We didn't kill this one, but rather demoted it as a dupe. Killing it would have closed it to additional comments, and we try not to do that when there's an ongoing discussion.
Not a laywer. Withdrawing and reapplying after changing the app, or responding to the RFE are both valid options. The only thing that is not useful is appealing a rejection. The appeals rarely work and are a waste of money and time. There was also an executive order about O1 which was supposed to lead to rulemaking that would make O1 and EB1 easier for AI (https://www.whitehouse.gov/briefing-room/presidential-action...). I don't know if anything came of this, but look into whether any rulemaking is happening and apply after a final rule is published, assuming you are doing AI. (Everyone is doing AI, btw).
> That's why the WordPress code is still spaghetti more than 15 years after it was originally launched. For the good of the customers.
Thats actually true. Backward compatibility was and still is the #1 thing in WP, and its why it won over the web: No small business or individual customer cares about 'better code' in the backend if those 'improvements' break their websites. This was what a lot of wordpress competitors did in the past and they suffered for it.
Unrelated to the blogpost in question but I don't understand why the author is not using its own certificate if he is using his own domain.
Using an browser set to autodirect to https by default, all I get is some huge warning because the host use a certificate for svbtle, the service used to host this blog.
I know some people think that because some blogpost is public it can be served without ssl, but I think it is still nice to leave the choice of the reader to disclose or not to his provider and everyone in between what he is reading or not without seeing horrible warnings.
I cut my Assembly teeth on S/360. In those days IBM source code was widely available and provided an excellent practice example for learning Assembler and the finer points of various instructions.
We should not forget that macro processing vastly expanded the power of Assembly language.
There is an analogy with DCF, Document Composition Language. The first MarkUp Language was GML which was a set of DCF macros.
GML evolved into BookMaster which underlayed IBM becoming the world's second most prolific publisher.
I wrote XPSProf which was a DCF ML used by Xerox Canada for writing manuals for its IBM compatible software offerings.
Jacques, be wary of taking piano technique to a harpsichord. Couperin's manual on harpsichord playing is entitled "L'Art de toucher le clavecin". Hard hands don't work well.
Also a harpsichord tone needs time to develop after the pluck. On a revival instrument, playing fast doesn't lose much. On an instrument built following historic practices, slower brings out the music.
Scott Ross once cautioned against playing comme une machine à coudre.
Peary took an iron meteorite from Greenland to the chagrin of the local Inuit who had been using it for knives. Whacking it with a rock in -40 temperatures might have been the mechanism.
Entering the US with a foreign passport and US birthplace can lead to a bunch of questions from US CBP as US citizens are required to reenter the US with a US passport (helps the IRS).
A number of provisions in the US Immigration and Nationality Act, INA, whereby somebody born in the US could lose citizenship have been repealed or declared unconstitutional. Lost citizenship was not automatically restored when the INA was amended. You would have to apply for reinstatement.
But the obligation and accounting fees to file tax and FATCA forms with the IRS are a major deterrent if you are living outside the US.
I had a long conversation inside a border post on this topic until suspected consultation with higher-ups at the Port office clued in the local officers and they suddenly said "Have a good day!" without further explanation.
Since then I've carried a copy of the State Department 7 FAM 1200 APPENDIX C, but haven't seen further CBP curiosity about my possible US citizenship; I suspect there is now a note in my file entry that I am not a US citizen.
In reality the title should be: this is how I got lucky in my journey, I jumped into the AI hype just like thousands of other developers, but pure luck made it for me, and now I make X amount of money. I’m not the first to jump into it, I’m not the brightest since there are way smarter people than me who tried similar ideas, I didn’t build anything groundbreaking, and I didn’t invent anything new. I just got lucky.
Now all you have to do is to sustain that, make an article about it, write a book on how you are successful and sell it because everyone subconsciously likes to read stuff that gives them hope, and maybe even later make a TED talk talking about how X attribute is all you need for success. But in reality, it is just luck! A lot of people did what OP did, and a lot will try to mimic it too, only to find out years later that they didn’t make it, ending up in a worse financial situation plus all the mental health issues they had/have to deal with. I am not trying to be pessimistic, but I always wish that in all these inspirational stories, they would make it clear that it is all luck. Sure, try your luck too, but keep your hopes just like how you do when you gamble.
> Are there any hidden details that are usually not mentioned?
Yes. In general there are hidden details but what those specifically are, I can't tell you.
I can speak freely since I was expelled from YC.
# Background
I did YC twice, in 2008 and 2009. YC invested ~$15,000 in both startups. I don't keep a close eye on it, but I think nowadays they give you 33.3333x as much money.
My first startup we shut down. I didn't know what I was doing. My co-founder was smarter and went on to do multiple successful companies, I think a couple funded by YC.
My second company got acqui-hired by Microsoft in 2014. YC got $0 since it was only 3 people and YC was our only investor and it wasn't worth it to do a stock acquisition, especially since the Seahawks had just won the Superbowl and the Microsoft Biz Dev folks were in a good mood.
I felt relieved I could at least "pay back" YC, but PG was aghast when I emailed him that: "You don't have to pay back YC. I'd be horrified if I thought you were even thinking about that. We expect to lose money on most of our investments. The small number of big hits compensate-- more than compensate. So don't worry about us at all. Just go work on interesting things. Good luck, --pg"
Ignore how he dresses, the guy is a class act.
# As to the Hidden Details
There's a lot of secrets with YC.
Back in the early days when I was just one of the first HackerNews users, I logged into the site and saw I had "One New Message". WTF?
HN did not have a messaging system.
Or so I thought.
In fact, HN had a secret messaging system that PG used to communicate with promising hackers.
From that point on I was a guest in YC's secret hotel, but never got invited up to the Penthouse.
YC has a lot of hidden tools. I am now on the shittier version of HackerNews that the public has access to (since I got expelled). There's a cooler version with extra features that you get access to if you're in the club.
YC has secret ratings and reviews of all investors worldwide; a huge thing called "Bookface" with all sorts of helpful tools for startups, etc.
They don't really share anything about their returns. They are not like Warren Buffet, who writes a detailed letter explaining the returns each year.
Knowledge is compartmentalized a lot of knowledge between partners, batches, LPs, favorite startups, et cetera.
Now, there are legitimate reasons for doing this.
First, it's obviously a huge competitive advantage, and IMO these tools and this information is likely worth far more than the $500K they give your startup.
Second, YC/their portfolio is _constantly_ under attack from forces all over the world. That's what happens when you are the GOAT and fund so many Unicorns. People all over the world come after you and your portfolio companies. Tom Brady is a hero in Boston and Tampa but the most vile villain in 94% of cities with NFL teams. You get paid the big bucks not to enjoy the love, but to endure the hate.
Anyway, so what specifically are the hidden details? I don't know. Like I said I was never invited up to the Penthouse. But I do know they are more than comfortable to keep secrets. Secrecy does not seem to bother them.
Don't take my word for it. Here's JL: "Some of the most useful things I've learned about startups over the years are also things I'd never share publicly." [0]
If they are holding back "the most useful things", what are they giving us? Why should we trust them?
I'd recommend against it, but then again, I'm building software products in this exact space with my launching customer being a 200-300M annual revenue logistics company. I don't think they could do it in-house. You don't give a lot of info on the exact niche you are in, but the username tells me that you're doing containers in European context, most likely shortsea or domestic, not deepsea. Me telling you the ISO6436 type code for your username is either LEG1 or LEGB depending on max stacking height should tell you I know my stuff :)
Your biggest pain point is most likely that you know your business very well, but you probably do not know enough about the business context of your partners. If you are running a small-ish container terminal for example, you really should know how the depot department of the major carriers are managing their empty stock so you can decide your stacking strategies in the yard. You should probably also have an understanding of benefits vs drawbacks of tower cranes vs gantry cranes found at bigger quays. That then influences what your TOS should be capable of. Same thing goes for intermodal transport planning, you really should know not only how detention/demurrage works, but also what tricks you can pull to optimize for it, and how shipping lines monitor this internally. If you are building stuff in-house, you're inevitably going to be limited in your understanding of the wider market. Short term that's a huge improvement (more tailored software, better flexibility), long term that might cause huge issues.
I can certainly understand the frustration with third-party products. Your description of 'they are understaffed and the platform is stagnant' could realistically apply to pretty much any software provider in this space. There is a huge opportunity for somebody to swoop in and build something, the bar for this sector is mostly something that doesn't straight up suck. And I'm going to be honest: we're trying to be that somebody.
If you'd like to talk, my contact details are in my profile. I'm happy to show you what we're building, and tell you what that is like behind the scenes. If you go ahead with your plan to in-house it, let's stay in contact, perhaps we can learn from eachother.
> you don't need a special debug build to be able to debug
Note that this is highly dependent on choice of compiler. Clang is utter crap for debugging even at -O1, but I've encountered basically no trouble ever using GCC at -O2 (you do have to learn a little about how the binary changes but that's easy enough to pick up). I really would not recommend -O3; historically it introduced bugs and regardless it makes the build process much slower, and the performance gain is fairly negligible (I can't say how much it destroys debuggability due to lack of experience). I can't speak for MSVC personally but it's a bad sign that its culture strongly promotes separate debug builds.
That said, sanitizers are a place where a special debug build does help. Valgrind can do many of the things that sanitizers can but is around 10× slower which is a real pain if you can't isolate what you're targeting, so recompiling for sanitizers is a good idea.
(Other brief notes)
I have never actually encountered a case where the lack of frame pointers actually caused problems. As far as I'm concerned, any tool that breaks without them is a broken tool. (Theoretically they can speed up large traceback contexts if you're doing extensive profiling; good API design probably helps for the sanitizers case here)
Rather than assembly int3, Unix-portable `SIGTRAP` is very useful for breakpoints; debuggers handle it specially. You can ignore it for non-debugged runs but get breakpoints when you are debugging without changing the binary or options! Alternatively you could leave it unignored if you have tooling that dumps core or something nicely for you.
Testing for most organizations is usually either really, incredibly expensive or an ineffective formality which leaves them at more risk than it saves. If you aren’t going to do a full run through all of your applications, it’s probably not doing much and very few places are going to invest the engineer time it takes to automate that.
What I take from this is that vendors need a LOT more investment in that work. They have both the money and are best positioned to do that testing since the incentives are aligned better for them than anyone else.
I’m also reminded of all of the nerd-rage over the years about Apple locking down kernel interfaces, or restricting FDE to their implementation, but it seems like anyone who wants to play at the system level needs a well-audited commitment to that level of rigorous testing. If the rumors of Crowdstrike blowing through their staging process are true, for example, that needs to be treated as seriously as browsers would treat a CA for failing to validate signing requests or storing the root keys on some developer’s workstation.
The only surprising thing is that this doesn't happen every month.
Nobody understands their runtime environment. Most IT org's long ago "surrendered" control and understanding of it, and now even the "management" of it (I use the term loosely) is outsourced.
* lights out interfaces not segregated from business network. Bonus points if its a supermicro which discloses the password hash to unauthenticated users as a design features.
* operational technology not segregated from information technology
* Not a windows bug, but popular on windows: 3rd party services with unquoted exe and uninstall strings, or service executable in a user-writable directory.
I remediate pentests as well as realworld intrusion events and we ALWAYS find one of these as the culprit. An oopsie happening on the public website leading to an intrusion is actually an extreme rarity. It's pretty much always email > standard user > administrator.
I understand not liking EDR or AV but the alternative seems to be just not detecting when this happens. The difference between EDR clients and non-EDR clients is that the non-EDR clients got compromised 2 years ago and only found it today.
Long time ago I was working for a web hoster, and had to help customers operating web shops to pass audits required for credit card processing.
Doing so regularly involved allowing additonal ciphers for SSL we deemed insecure, and undoing other configurations for hardening the system. Arguing about it is pointless - either you make your system more insecure, or you don't pass the audit. Typically we ended up configuring it in a way that we can easily toggle those two states, and reverted it back to a secure configuration once the customer got their certificate, and flipped it back to insecure when it was time to reapply for the certification.
Those able to write and use FUD malware do not create public documentation. Crowdstrike is not impossible to bypass, but for a junior security journeyman known as a pentester, working for corporate interests with no budget and absurdly limited scopes under contract for n-hours a week for 3 weeks will never be able to do anything as simple as an EDR evasion, however if you wish to actually learn the basics the common practitioner of this art please go study the offsec evasion class. Then go read a lot of code and syscall documentation and learn assembly.
Crowdstrike though is not part of a system of engineered design.
It’s a half-baked rootkit sold as a figleaf for incompetent it managers so they can implement ”best practices” in their companys PC:s.
The people purchasing it don’t actually know what it does, they just know it’s something they can invest their cybersecurity budget into and have an easy way to fullfill their ”implement cybersecurity” kpi:s without needing to do anything themselves.
This event is predicted in Sydney Dekker’s book “Drift into Failure”, which basically postulates that in order to prevent local failure we setup failure prevention systems that increase the complexity beyond our ability to handle, and introduce systemic failures that are global. It’s a sobering book to read if you ever thought we could make systems fault tolerant.
Did they refuse to pay actively ("We won't pay you."), or passively (No replies to emails.) The latter might be incompetence.
As others mentioned, specific legal advice depends on respective jurisdictions, but an offical lawyer's letter sometimes wakes up legal when accounting is drifting.
Did you deliver the final access to the code / server / credentials? If not, gently bring servers, DBs, platforms to a halt pending final payments.
Future projects:
Contract, always.
Up-front commencement payments, always.
Price yourself higher in the initial quote, and ask for staged payments, such that by the time your delivery schedule is 50-75% done you are 100% paid.
You control the source code accounts, you control the server credentials, you control the database access credentials, you hand over final access after the final check has cleared.
- no weave. Without going into a lot of detail, suppose someone adds N bytes on a branch and then that branch is merged. The N bytes are copied into the merge node (yeah, I know, git looks for that and dedups it but that is a slow bandaid on the problem).
- annotations are wrong, if I added the N bytes on the branch and you merged it, it will (unless this is somehow fixed now) show you as the author of the N bytes in the merge node.
- only one graph for the whole repository. This causes multiple problems:
A) the GCA is the repository GCA, it can be miles away from the file GCA if there was a graph per file like BitKeeper has.
B) Debugging is upside down, you start at the changeset and drill down. In BitKeeper, because there is a graph per file, let's say I had an assert() pop. You run bk revtool on that file, find the assert and look around to see what has changed before that assert. Hover over a line, it will show you the commit comments to the file and then the changeset. You find the likely line, double click on it, now you are looking at the changeset. We were a tiny company, we never hit the claimed 25 people, and we supported tons of users. This form of debugging was a huge, HUGE, part of why we could support so many people.
C) commit comments are per changeset, not per file. We had a graphic check in tool that walked you through the list of files, showed you the diffs for that file and asked you to comment. When you got the the ChangeSet file, now it is asking you for what Git asks for comments but the diffs are all the file names followed by what you just wrote. It made people sort of uplevel their commit comments. We had big customers that insisted the engineers use that tool rather a command line that checked in everything with the same comment.
- submodules turned Git into CVS. Maybe that's been redone but the last time I looked at it, you couldn't do sideways pulls if you had submodules. BK got this MUCH closer to correct, the repository produced identical results to a mono repository if all the modules were present (and identical less whatever isn't populated in the sparse case). All with exactly the same semantics, same functionality mono or many repos.
- Performance. Git gets really slow in large repositories, we put a ton of work into that in BitKeeper and we were orders of magnitude faster for things like annotate.
In summary, Git isn't really a version control system and Linus has admitted it to me years ago. A version control system needs to faithfully record everything that happened, no more or less. Git doesn't record renames, it passes content across branches by value, not by reference. To me, it feels like a giant step backwards.
Here's another thing. We made a bk fast-export and a bk fast-import that are compatible with Git. You can have a tree in BK, have it updated constantly, and no matter where in the history you run bk fast-export, you will get the same repository. Our fast-export is idempotent. Git can't do that, it doesn't send the rename info because it doesn't record that. That means we have to make it up when doing a bk fast-import which means Git -> BK is not idempotent.
I don't expect to convince anyone of anything at this point, someone nudged, I tried. I don't read hackernews any more so don't expect me to defend what I said, I really don't care at this point. I'm happier away from tech, I just go fish on the ocean and don't think about this stuff.
This is completely untrue. There is no way that you could make a BK clone by telneting to a BK and running commands. Those commands don't tell you the network protocol, they show you the results of that protocol but show zero insight into the protocol.
Tridge neglected to tell people that he was snooping the network while Linus was running BK commands when Linus was visiting in his house. THAT is how he did the clone.
The fact that you all believe Tridge is disappointing, you should be better than that.
The fact that Tridge lied is disappointing but I've learned that open source people are willing to ignore morals if it gets them what they want. I love open source, don't love the ethics. It's not just Tridge.
Come on, man, you should be better than this. With so many years of hindsight surely you realize by now that reverse engineering is not some moral failing? How much intellectual and cultural wealth is attributable to it? And with Google v. Oracle we've finally settled even in the eyes of the law that the externally visible APIs and behavior of an implementation are not considered intellectual property.
Tridge reverse engineering bk and kicking off a series of events that led to git is probably one of the most positively impactful things anyone has done for the software industry, ever. He does not deserve the flack he got for it, either then or today. I'm grateful to him, as we all should be. I know that it stings for you, but I hope that with all of this hindsight you're someday able to integrate the experience and move on with a positive view of this history -- because even though it didn't play out the way you would have liked, your own impact on this story is ultimately very positive and meaningful and you should take pride in it without demeaning others.
He should look into C, not C++. With Duff's device[1] trick, it becomes surprisingly lisp- and forth-y. It can be used to implement coroutines in 100% portable C[2]. And I'm pretty sure you can use the same trick to implement infinite recursion (stack on heap) and maybe even backtracking a la prolog.
I've written some: a programming language interpreter based on Abadi and Cardelli's untyped ς-calculus; a two-kilobyte web server in assembly (which accidentally did turn out to be useful); a self-compiling compiler from a sort of Forth dialect to i386 ELF executables; a translator from standard English orthography to an ASCII alphanumeric phonetic orthography I designed; a one-kilobyte programming language interpreter with dynamic multimethod dispatch and pattern-matching; a base-3 calendar based on the Sierpinski triangle; a C interpreter in Python I used for bytebeat livecoding; several implementations of Tetris, one of which is a 2K ARM executable; an operating system for ARM consisting of five instructions; a few raytracers; a Space Invaders game; a minimal roguelike in Forth; a library for manipulating Boolean functions as Zhegalkin polynomials; many symbolic differentiators; a sort of polyrhythmic drum machine called Pygmusic; a parametric CAD system in PostScript for laser-cutting MDF; 3-D rotating objects in ASCII art in 20 lines of Python; Karplus-Strong string synthesis in one line of C; an audio PLL in one line of C; an RPN calculator with forward-mode automatic differentiation; a slide rule in Tcl/Tk; a port of the logic-programming EDSL μKanren to OCaml; several fractal renderers; a decoder for the "gridfonts" Hofstadter and his research group designed; a Hershey font decoder; several maze generators; a generator for balanced-nonary multiplication tables; a vocoder; a Doom-like first-person raycaster; a teapot mod for the Minetest game; a compiler for a subset of Scheme written in itself; etc.
A lot of this is in http://canonical.org/~kragen/sw/dev3/ which you can clone with Git. I'd be happy to elaborate on any of these if you are interested.