catwell

WebGPU does not play in the same league as tfjs, it is a successor to WebGL, the technology tfjs is implemented with. There is already a WebGPU backend for tfjs: https://www.npmjs.com/package/@tensorflow/tfjs-backend-webgp...

There are also several ONNX runtimes using WebGPU in case you want to run models written with PyTorch.

> While PyTorch is obviously the future in the short term

Well, that's not obvious for me. The metrics do not support the death of Keras / TF (https://twitter.com/fchollet/status/1614322127460782087)

François Chollet's Deep Learning with Python is arguably the best book on the topic and teaches people using Keras / TF2. The Keras documentation is excellent as well, and in the long run it will matter. Personally I prefer the way the Keras / TF2 APIs work to PyTorch as well.

Also, I am pretty sure a JAX backend is coming to Keras, and there is TF Lite...

I cannot make a prediction as to which stack will dominate in five years.

That depends a lot on what that CV application does and what hardware it runs on. Naive C++ (that runs on CPU) is usually much slower than using Python as glue for libraries that run on GPU.

1. Make sure your business model doesn't mean growth will kill you.

@armc's first point "Few business problems can't be solved by more sales." is important, but here is a case where it doesn't work (on the contrary).

I once (indirectly) worked for a startup whose business model was basically to rent expensive hardware to its customers. It was considered a rising star, but here's the problem: it had exponential growth. That meant exponential capital needed to buy hardware.

It was considered a rising start, most of its metrics were incredible. Given unlimited access to liquidity it would have easily IPOd by now. But there is no such thing, so it crashed and burned.

(The product still exists but they took measures to address that problem, and the growth is hardly what it once was.)

2. Money doesn't exist until it's on your bank account.

Another startup I worked for (you might guess which one) raised a round with a new fund as the lead. For various reasons that fund couldn't give us the money for a whole year and that locked the other funds as well.

That startup was selling hardware. With no money in the bank we couldn't pay the factory or shipping. We had endless pre-order lists. When the money finally arrived, we had had a whole year with basically no sales, and that ended up being fatal.

3. Some customers aren't rational and that's fine.

At a startup I worked for some time ago, a customer bought an expensive yearly license for our product and never even used it once. At the end of the year, they came back... and renewed the license. I think we actually asked them if they were sure, and they said yes. They didn't use the product for yet another year.

4. Only found a company if you understand the field.

That one is from my experience as a founder. I was the technical co-founder of the company but I had no previous experience or knowledge of that specific market. I thought that was fine because I had a great co-founder who did and very serious partners, so I could learn as I went.

As it turns out we realized quickly that all our initial market study had important flaws an our assumptions didn't hold. We then went into a mode where we tried to figure out if we could turn the company around or maybe pivot, and that was a very frustrating time for me because I felt powerless, not having the necessary knowledge to help like I would have wanted to do.

Thankfully I had enough experience with other businesses to look at the metrics and figure out a few key things. Eventually we shut the company down and it was the right decision, but I will never again start a company in a field I don't know well.

5. Everyone on support.

I have done support one way or another at every single company I worked for. At the company I currently work for everyone works L1 support in rotation and I strongly believe it is a good thing. It will ensure everyone talks to customers and is aware of their pain points.

I wrote a blog post advocating for something like this recently, with an additional push to notify the client when it should poll: https://blog.separateconcerns.com/2022-03-05-push-to-poll.ht...

I wasn't aware of this but it fits the use case perfectly, I will update the post.

The compile times are part of the reason why scripting languages like Lua are popular in games. In engine code it's fine, but you don't want to wait minutes to see a change while working on higher-level parts of the game.

The data thing though, that sounds like your engine is poorly optimized for development time. There should be a way to work with data without repacking everything.

This point makes literally no sense to me. He says don't start coding before you fully understand the problem, and then he says the way to explore the problem space is coding (the code-test-improve cycle).

By the way I agree with the last part. Sometimes the best way to understand the problem is writing a half-broken solution for it. You just have to be aware that what you're writing probably won't solve the problem, and make sure all the other stakeholders are aware too (that's usually the hardest part).

Disclaimer: I am French and I had servers (well, my employer did, and I was the admin) in that DC.

From the report (not the post): something that really annoyed the firemen is that not only was there no universal electrical cut-off, there were 4 different electrical backups, which they had to figure out how to cut off one by one...

It's the same thing as the self-cooling design: OVH optimized for what typically matters in a DC. You want an energy-efficient design and you never want power to go down.

Well... except when you do. I suppose by now them and other hosting providers have taken that issue into account and are modifying their DC designs accordingly.

I am not blind myself, but I have been using Linux for over 20 years and followed a few blind people who got into it.

If your friend wants to go the Linux route, I would suggest to pick a distribution with a blind community and if possible blind developers. Arch Linux would probably work, and I am pretty sure Debian too since a recent Debian Project Leader (Sam Hartman) is blind. There is also a Slackware derivative called Slint.

Regarding tools I have seen blind people use different things. Some use the CLI exclusively with a braille terminal and/or a tool like Speakup, others use GUIs like Orca.

There is a mailing list dedicated to blind Linux users: https://listman.redhat.com/archives/blinux-list/

Note: I'm not suggesting your friend picks Linux, it looks like accessibility on Windows is better, but I know if I was in their situation I would probably still pick Linux because I already have experience with it and using an OS without a GUI.

Best of luck to you and your friend!

> Yes, there are SQL databases out there that run on the client side or have replication, but not both.

Yes, there are. https://zumero.com for instance.

This is a slightly simpler (because of unicity) version of bucket sort or counting sort.

You probably can and it won't be nearly as bad as what it is on MacOS. You only need a code signing certificate for drivers from Microsoft. You might not even need that if WinFSP provides signed binaries and you don't modify the driver part.

(Source: until 2 years ago I used to work at a company that did that using a proprietary driver - CBFS - and was looking at WinFSP to replace it.)

Yes, that would be:

    method = o.method(:my_method)
    method.call(5)
    # or method[5], or method.(5)

If you really want a "function" that you can call with parens:

   Kernel.define_method(:method_as_fun, &method)

(Definitely don't do that last bit in a real project...)

(disclaimer: IANAL)

You have basically just given a justification that crash reporting can be conducted based on legitimate interest instead of consent, and as such does not require opt-in.

Many people mistakenly believe consent is the only possible justification for data processing under GDPR, whereas there are actually 6 possibilities, and you can ask a lawyer which one can apply for a given data processing flow.

Note that whereas I do believe that crash reporting can indeed be considered legitimate interest, I wouldn't consider plain telemetry ("phone home without a technical good reason") to fall under that umbrella...

It is super nice seeing Berty on the HN front page. I know the founder, who has done many things before among which initiating the Paris P2P meetup (https://p2p.paris), so I've been hearing about it for over a year now. Hopefully the app will be available to the public soon!

You didn't get the joke. Hint: case matters (and look at that repo :p).

The push mechanism, for one.

IMAP has one (two actually, IDLE and NOTIFY) but they are not really adapted to the way we use email today (mobile and browser-based apps).

> If you have the option of writing an SPA, it's simpler quicker to build this way, and so easy to deploy.

It's simpler if you only write the front-end, because it de-couples the work with the back-end.

If you are in charge of both front-end and back-end, server-side rendering is easier.

It's a case of Conway's Law. Knowing that, you may choose to have a back-end team and a front-end team or a team of full stack developers depending on the end result you want.

Personally I think it depends on whether the Web is just another client for you, which consumes APIs like native applications, or if your product is entirely web-based.

They didn't start from scratch, Zircon is based on lk which they already used in Android.

That also exists in France (and is currently used extensively) but it's very different from reducing salaries.

I am an Arch Linux laptop user. Plain RDS through Remmina works great for Windows machines. When not usable, I found AnyDesk to work fine-ish (but it changes system keyboard settings, which is annoying). I can't use TeamViewer which still doesn't support Wayland.

This is fine, but it is yet another molecular test. What we need now are serology tests. They are faster, cheaper, easier to execute (blood-based), can detect cured patients, and can scale to the population of a country.

Serology tests are already used in several countries in Asia, I have little doubt they will arrive in Europe and the US soon-ish.

https://en.agricool.co is a French startup perfecting its technology to grow fruit (they focus on strawberries) in containers, within cities, using very little water. They raised €25M last year.

In software, I am hopeful for applications of homomorphic encryption. It could solve some privacy issues preventing some classes of software from moving to the Cloud. There have been huge efficiency improvements over the last 10 years, there needs to be even more, probably hardware-assisted.

In general, climate change is the topic of the century, and with it energy generation and storage. I think intermittent renewables (wind and solar) are overvalued today. Nuclear fission has a large role to play (with SMRs for instance), hydrogen as well. Of course if we make fusion work all bets are off.

> it was the SIF clause that allowed them to block the deal

Not that I know of. The SIF didn't have any ownership of Dailymotion anymore. Their shares had been bought by Orange.

Montebourg just said publicly he wouldn't let Orange sell, and it killed the deal.

Only slightly related: why do French startups need to take State money? Because we have much less private investment, in part due to our social model. We don't have many pension funds because most of the retirement system is state-owned, we have few private universities because the best part of the higher education is state-owned... So basically we have no LPs.

Many French startups, probably most of those you know, take State money in their early rounds. The State has a fund (BPI) whose policy it is to co-invest with the major French VCs. They have favorable terms for startups.

That being said, in general, the state is a passive investor. What happened with Dailymotion is way different.

First, the issue came from Arnaud Montebourg, a powerful Minister of the Economy with statist views in the former Socialist government. The current government is very different. (By the way, Montebourg was replaced by Emmanuel Macron, the current President of France, as Minister of the Economy under Hollande.)

Second and most important, by the time this happened Dailymotion had already been sold. It was a wholly owned subsidiary of France Télécom, the largest telecommunications operator in France (commercially known as Orange). That operator was state-owned until 2004, and even today the State is its largest shareholder.

In other words, the State prevented a former public company it basically still controlled from selling a wholly-owned subsidiary which happened to be a startup it bought before. I disagreed with the decision then, and I still disagree today, but it didn't prevent an exit. Rather, the actual exit of Dailymotion was to a company owned in part by the State...

EDITS:

- Looks like I was too slow to post and senko beat me to it.

- The "FSI" articles linked by others talk about, which invested in Dailymotion, is now part of the "BPI" I mentioned (it was merged with other vehicles that invested at different stages).

- Some French people regret Montebourg style, for instance a journalist recently tweeted his disagreement about the governmental OK to the sale of Photonis, a night vision company, to a foreign group (https://twitter.com/VincentLamigeon/status/11742379454543708...).

At Uber scale, you probably already have your own SMTP servers used by all your employees, so that's not really a problem.

Moreover, email is hard and does require a dedicated team, but the order of magnitude is wrong here. 5 people is plenty.

Some startups don't fall in those categories, for instance https://www.sqreen.com which recently raised $14M from Greylock.

Abstract: In September 2019, voters for the election at the Parliament of the city of Moscow will be allowed to use an internet voting system. The source code of it has been made available for public testing. The encryption used in this system is a variant of ElGamal with key sizes that are too small. We explain how to retrieve the private keys from the public keys in a matter of minutes with easily available resources.

Notes:

- Not mentioned in the abstract but the system relies on an Ethereum smart contract.

- The author is a researcher at Loria Nancy (France) which I consider to be one of the best teams in the world on this topic. Among other things he worked on Belenios (http://www.belenios.org/index.html).