I'm glad that we're on the same page on this. Your motivation is totally understandable and the end result (including relevant blog post) is both very nicely done and educational. Thank you for this and your other resources that you share online! :-)
This is pretty cool, kudos to the author. However, I'm curious about why would you want to use a genetic algorithm (GA) for what is clearly a relatively straightforward computer vision (CV) problem. I would argue that the GA-based evolutionary solution is no simpler and, more importantly, will not only never outperform the CV-based one in terms of accuracy and speed, but will be orders of magnitude slower.
I'm not sure why that would be the case here. Unless, for some reason(s), he has sold most of his share of the company to Sytse, I don't see why Dmitriy would own less stock than his co-founder. Especially considering that Dmitriy has started the relevant open source project prior to Sytse's involvement and then, after the company's formation, has actively participated in technical decision making and software development.
I think that the most fascinating fact about this upcoming IPO is that, to the best of my knowledge, GitLab is the first remote-only (i.e., no-headquarters) company in the world filing for an IPO. In any case (meaning even if I'm wrong that they are the first), I wish them luck and welcome the competition.
It's interesting to see that GitLab has adopted dual-class common stock structure, though I'm certainly not surprised. Some people and organizations (including some investment firms and stock exchanges) are not fans of multi-class equity structures, but I'm not sure that this fact would have any significant negative impact on GitLab's IPO. At least, these popular 10:1 or slightly less popular 20:1 voting schemes are not as aggressive as Palantir's three-class stock structure, where Class F (just three founders - out of five!) would hold practically 50% of the total voting power.
One strange thing that I've noticed while browsing through this S-1 document, though, is the lack of mention of GitLab's co-founder (Dmitriy Zaporozhets) in the stockholders table (p. 148). I would expect him to hold about the same ownership of the Class B shares as the other co-founder Sytse Sijbrandij holds, but definitely more than 5%, which requires a disclosure there. I'm not sure how to interpret the absence of his name.
> MySQL, an open source database developed by Oracle
Dear Facebook:
Please fix the wording emphasized above ASAP before we revolt here in outrage with your lack of attention to detail. MySQL was developed by relevant open source project contributors (initially, MySQL AB folks), but not by Oracle and even not by Sun Microsystems. MySQL has been in development for ~12 years before Sun acquired MySQL AB. Please set the record straight.
Sincerely,
MySQL user (not currently, but in the past and maybe in the future [though unlikely, because Postgre...] :-)
I think that all this boils down to a rather simple dilemma for modern cloud-native infrastructural platforms [in terms of developer experience, i.e., external APIs etc., not internal architecture; and this is not even limited to this class of systems - it is general concept for all software systems]: a) universal, highly configurable & complex (K8s) OR b) highly opinionated and [relatively] simple (e.g., Nomad/Waypoint, Heroku, Apollo, CapRover, Dokku, Porter, AWS Elastic Beanstalk, Digital Ocean's App Platform, Fly, Render). Obviously, there exists a middle-ground category as well: relatively simple, but still opinionated and moderately (???) or highly (e.g., OpenShift) configurable platforms. Thus, the optimal choice depends on relevant team's or organization's priorities with respect to those attributes (configurability, complexity, level & scope of opinionation) as well as level of organizational standardization for IT environments, economic factors, vendor lock-in considerations and, perhaps, something else that I forgot to mention).
This is a highly dynamic market: from rapidly (in some geographies) developing charging infrastructure to EVs becoming nicer, cheaper and with higher range. Two recent news in this regard are quite notable: a) Elon Musk announcing opening Tesla's Supercharger infrastructure to non-Tesla cars later this year and b) Chinese EV manufacturer Xpeng pricing base model of their new sedan P5 at less than $25K (beating Tesla at bringing the price of a solid EV down to that critical level).
> Copyright has concluded that reading by robots doesn’t count. Infringement is for humans only; when computers do it, it’s fair use.
This is a ridiculous conclusion. The ultimate destination of the robot actions' product is its user, i.e. a human. It is a clear corollary of the transitive law. Therefore, all human-focused legal concepts, including infringement, are applicable in such cases.
The absurdness of the conclusion cited above can be easily illustrated, as follows. Suppose that a person owns or rents an advanced robot (say, like Boston Dynamics' Spot, but better). He/she then programs it to break into someone's house and steal something valuable. All goes by the plan, the robot delivers the stolen goods to the rendezvous point and, if rented, gets returned. Now, according to the conclusion's logic, since a robot has done the actual "work", "it's fair use". Nonsense, right?
Just to clarify: I like the concept of GitHub Copilot (even though I have not yet tried this particular product). It offers various benefits, from pedagogical to adopting software engineering best practices to improving engineering productivity. However, I think that IP and legal aspects of this approach and specific product should be carefully studied and resolved in a consistent manner (e.g., prevent the model or system to output exact source code snippets).
I certainly see the value in solutions like GitHub Copilot (if implemented well), at least, from three perspectives: a) 𝐩𝐞𝐝𝐚𝐠𝐨𝐠𝐢𝐜𝐚𝐥 (by allowing developers, especially beginners, to see the diversity in different approaches to potential solutions for specific problems), b) 𝐬𝐨𝐟𝐭𝐰𝐚𝐫𝐞 𝐞𝐧𝐠𝐢𝐧𝐞𝐞𝐫𝐢𝐧𝐠 𝐛𝐞𝐬𝐭 𝐩𝐫𝐚𝐜𝐭𝐢𝐜𝐞𝐬 [of course, it should be used with care and, generally, the quality of relevant suggestions from this angle is still TBD] and c) 𝐢𝐦𝐩𝐫𝐨𝐯𝐢𝐧𝐠 𝐞𝐧𝐠𝐢𝐧𝐞𝐞𝐫𝐢𝐧𝐠 𝐩𝐫𝐨𝐝𝐮𝐜𝐭𝐢𝐯𝐢𝐭𝐲 (this is especially relevant for programming languages and frameworks with lots of boilerplate code - e.g., C#/.NET, Java). Spending much less time on typing typically very verbose boilerplate code will give software developers much more time to spend on truly valuable and important activities, such as problem solving, architecting, collaborating.
Never heard about this company before. Took a quick look at their website and noticed that in the table on front page (located in the section "Vetted by the NSA") Zoom is listed as a product lacking "Full E2E Encrypted Functionality". I'm wondering about whether this isn't true (considering Zoom's E2E being GA: https://support.zoom.us/hc/en-us/articles/360048660871-End-t...) - and the table should be fixed - or still true (due to aspects that I might be missing).
I'm wondering about a) whether Vercel allows building full-blown Vue SPAs (with backend being independent from Vercel cloud infrastructure) and b) whether solutions built using Vercel are portable to any other cloud infrastructure (i.e., no vendor lock-in). Would appreciate if someone from Vercel team or HN community clarify these aspects.
Fair enough. Your decision to focus on one platform first, while still maintaining a relatively generic / flexible codebase, is definitely the optimal one. My interest in Vue stems from me selecting it as a front-end framework (FEF) of choice for my startup (work in progress). I have selected Vue after doing some relevant, but limited, FEF research; however, I might change my mind and go the React way at some point in the future. I'm certainly technically minded, but not an expert in JavaScript and Vue/React. So, while I love helping others, where possible, I'm most likely not the best person to help you explore the potential Vue support for your product. I might be a future user, though. Good luck!
Oops, I'm sorry! Perhaps, I have focused so intensely on the content of so many interesting discussions on HN that I somehow totally missed that control (unexpectedly to me, located on right side of the anchor label). Thank you for pointing at it and please accept my sincere apology for unwarranted criticism, which, obviously, I'm retracting. :-)
It certainly would be nice. I have an off-topic, but, nevertheless, important request in the question format: is there any chance that HN UI will be improved in the nearest future by allowing users to selectively expand & collapse individual discussion threads? The lack of this feature is IMO a very annoying issue and a glaring example of how simplicity taken to an extreme leads to a significant friction in UX (which arguably could be fixed relatively easily in this case).
I'm well aware of this practice and have no objection to it, in general. However, unless a company provides enough relevant information (e.g., feature breakdown per tier, other details) on the pricing page, IMO it could be better implemented as a button, link, one-liner or other compact visual element located on the home page, without wasting time and effort on repeating - and maintaining - essentially the same marketing copy on a separate page (as is the case here).
I wholeheartedly agree. There is certainly a correlation between seniority / scope and leadership. And, as you allude to, it is a positive one. My point in #1 was that they are separate entities with their own unique characteristics and I just wanted to emphasize that (despite the fact that the author of the original post has included some relevant leadership expectations in the list).