> I've got great experience with Indians working in Europe, not so great with Indians working from India. My impression is that the best Indian developers tend to move here, because they'll be able to earn European/American rates.

as an Indian developer working in the US, I have to say that this is a bit of an unwarranted stereotype, despite being repeated often on HN and Reddit

There absolutely is a large contingent of good developers in India (as you'd probably expect from a country with over a billion people), but they are mostly working with locally-managed projects and teams. A lot of them wouldn't work for outsourcing companies because of the poor pay and hours.

There is a bit of confirmation bias going on here: since western companies will frequently outsource to the low-cost shops in India, they will mostly see poor quality work. I don't think its fair to generalize this to all Indian devs.

If the likelihood is that he’ll never actually get to work with the most skilled devs, as per your own post, the de facto reality of his generalization is going to be true.

out of curiosity, how wide apart do you place the two halves of your split keyboard?

i recently got one, and been wondering if i should place them full shoulder width apart or not.

Given the stagnation that's set in the mobile form factor, i think its the perfect time for unwalled FOSS mobile environments to develop.

also, the demo with gesture typing on the console is pretty cool: https://postmarketos.org/static/video/2019-06/nexus5-shelli-...

The very first one was called Openmoko, released in 2007.

The people behind OpenMoko are amazing, and the tech they built for that still lives on in other projects like the Linux Kernel ist truly creative and trailblazing stuff.

They gave us a lot.

Do you have some examples of things from the OpenMoko days that still live on?

I got the impression that everything from then is either completely gone or no longer maintained. FSO, SHR, QtMoko, paroli etc are gone.

USB device mode in the Linux Kernel For example.

Yes, it's nice to see that pmOS is already enabling experimentation into such things as graffiti-like gesture input. ISTR that people used to be quite proficient w/ the old graffiti system when it was around, so this might turn out to be the most usable input system on these devices, at least for power-users, and until wholly-open voice-recognition systems become viable.

I used this setup daily on a geeksphone keon for about a year. I liked it quite a bit. Sadly the screen got broken and 2G service was getting bad. :) I hope to bring this fun experience to another phone with pmos. After the modem starts working I can pull together what I had before for texting and contacts and push it to the shelli repo.

I also experimented quite a bit using pocketsphynx for voice recognition and espeak for synthesis. Some things worked pretty well if I kept the set of recognizable things small, which I liked anyway.

used / refurbished iPhone SEs still work beautifully...i got one a few months ago and i've had zero issues with it

its not really "top of the line" anymore, but the fact that its light on the wallet (~$250) is another major benefit

But more than likely it won’t be supported with iOS 14. The 6s/iPhone SE is the oldest hardware that will run iOS 13.

Honestly with 1password integration I'm pretty ok staying on iOS 12, that's pretty much the last itch I have that Apple's likely to scratch. I love my SE and would be very happy to get another 5 years out of it. It's the perfect size for my pockets & has a headphone jack. I do miss the big screen for GPS but that's about the end of my complaints.

Gentoo also seems to have updated firefox-bin (and possibly www-client/firefox too?)...I ran an emerge update a few minutes ago and saw it install the firefox update

I think the question of "Why does it takes fifty lines to create a dialogue with a button" is very programming-language dependent:

If you're working with a higher-level programming language, you can make cross-platform GUIs very easily (see tkinter + python as others have recommended) without having to write 50 LOC.

If you're working with C / C++ specifically, then your bottleneck really is figuring out how to build and link with your cross platform library across all platforms. In my experience that has been much more painful than the lines of code required to set up a GUI in C++.

Once you've got the build/deployment system working in C++, most GUI libraries don't need as much as 50 lines of code. For example, even with Qt this is the code to get a dialogue with a button:

    #include <QApplication>
    #include <QPushButton>

    int main(int argc, char **argv)
    {
     QApplication app (argc, argv);

     QPushButton button ("Hello world !");
     button.show();

     return app.exec();
    }

In newer low-level languages with sane standardized package managers, like Rust, things should be much better, but I'm finding any good examples right now

Especially, it takes one line in almost all toolkits to create Standard dialogs such as

   window.alert("Hello world");

You can show such windows even from the terminal in Powershell, Linux, OS X. With one line of code.

It's not everything so broken...

A message box is not the same as a dialog with user controls.

All major toolkits have confirmation modal windows, input modal windows, etc as single line "calls". Of course it's not a "custom window" but it is one.

Yeah, I understand the pains of implementing native GUIs, but one of the niceties that they provide is that you can implement simple - moderately complex GUIs in fewer lines and cleaner APIs than what the cross-platform libraries provide.

I looked at Imgui before for a project, but decided not to go with it since the examples are all over a hundred lines long, for example:

https://github.com/ocornut/imgui/blob/master/examples/exampl...

It seems like there is a lot of setup / configuration code necessary to wire up Imgui with the graphics rendering back-end.

Note that I haven't used Imgui in a real-world project yet. Does anyone know of a better way to set-up Imgui that does't need all this configuration code?

Most of that code is incompressible to make a portable OpenGL app in C++, not really Dear ImGui's fault.

There's literally about ~10 lines of specific imgui code in there other than the 35 lines of example code in the middle of the main function.

Your problem is perhaps that you don't want to engage in actually reading that code.

People who aren't very tech/privacy-savvy, like elderly people, or kids/teenagers.

I remember signing up for facebook when I was in high school, and I probably would've provided my email password if facebook asked for it...as an adult now I wouldn't provide my email password to anyone, of course.