> because there's no well-defined meaning to the title of "CTO". Our "CTO" codes,
Amen.
I am a CTO, but spend most of my day coding. I was brought onto a smallish/medium sized company to get their base tech into the modern age, build LOB apps to improve some workflows, and ultimate build a new EMR in that space to replace the one the company is using.
I don't have anybody that reports to me. I'm one of 2 tech people in a company of clinicians and doctors. There is no budgeting or reports I have to generate.
But, it was the only title that made sense given my role in that specific company.
Anytime someone asks me I always have to add "but I don't really do CTO things".
so you’re not a CTO according to your own definition of what a CTO does then.
my previous employment i was “lead engineer”. i got to pick that title. had a 1 day per week part timer reporting to me. similar company description. making technical decisions. strategy meetings with CEO and founder etc.
i was not a lead engineer and ive since changed my linkedin page/cv to just say “engineer”. who or what was i leading? a contractor in ukraine who did work for us one day a week? nah, need a team (ie more than 1) to be able to lead.
do the brave thing and call bullshit on yourself. this is something good leaders do.
People here want "CTOs" to be brave enough to call bullshit on their "CTO-hood" but nobody here is brave enough to call bullshit on the title itself, which is the truer and more important observation.
> Lots of people don't even know how JavaScript works despite using it every day.
Imo every React course on the internet should start by having people implement a multi-step form wizard using solely Jquery. You don't appreciate where you are if you forget where you came.
I totally agree - the example they give doesn't really need react OR backbone. You could just as easily show vanilla js as the 3rd example and wonder why you would ever even need a framework.
One off it seems fine, but a huge backbone app gets really complicated for me. Show me a huge react app vs a huge backbone app and I will understand the react much more quickly.
"It's verbose, sure, but there's no mystery. A junior developer can trace exactly what happens and when. The mental model is straightforward: "when this happens, do this."
I don't think that's true. A large backbone app has a lot of code that you'll have to trace through multiple files in different directories - the template are here, the functions are there but the endpoints are over there and... maybe it's just the backbone app I have to update but it's much more confusing and abstracted than the react app I also have to update. And don't even get me started with adding a new component. I can drop a new component into the react app and import it anywhere and it's super fast and easy... backbone not so much.
> I don't think that's true. A large backbone app has a lot of code that you'll have to trace through multiple files in different directories
This is exactly my experience with large scale Backbone apps (from 10+ years ago). Even with extras like Marionette it quickly became a complete nightmare to navigate or maintain. Zombie model and view objects leaking memory was almost inescapable.
I remember in 2013 I introduced Backbone to my current company, hoping to make sense out of our existing jQuery + ASP.Net MVC application. After ~3 months of code from junior and mid level developers (in house and off shore) I began to deeply regret my decision. There was just not enough patterns and utilities in the framework to keep things from going off the rails. We eventually shifted to Angular v1 and it was glorious, things just worked and even the ceremony I needed to add felt worth the trouble for the speed of development we gained.
Angular v1 was absolutely the game-changer for sane UI patterns. Although it could choke on large datasets and models were iffy, it allowed us to worry less about the framework and more about the work at hand.
The guy who glazes JD Vance, the 1000000% alt-right Vice President who doesn't care about literal Nazis infiltrating his party is probably part of the alt-right.
> You couldn't kick your way through the 90s and 2000s without the endless parade of semi-transparent terminal windows running on various shades of windowmaker, enlightenment, kde, etc. all to show off how much more advanced the graphics pipeline and customisation was compared to Windows or Mac at the time. So this is hardly a new thing.
What does this even mean with respect to the article?
>This is such a reflexive and petty critique. How many real world security breaches happened because a login prompt that requires physical access limited to 10 tries instead of the "more cautious" limit of 3?
> Omarchy takes security extremely seriously. This is meant to be an operating system that you can use to do Real Work in the Real World. Where losing a laptop can’t lead to a security emergency.
lol Are you saying that a distro that makes this kind of claim shouldn't be concerned with the amount of times you can type in a wrong password? Especially since it's not vetting that actual security of the password itself?
How many times does your bank allow you to type in the wrong password? Is it 10? Cmon.
>lol Are you saying that a distro that makes this kind of claim shouldn't be concerned with the amount of times you can type in a wrong password? Especially since it's not vetting that actual security of the password itself?
It should, but anything below 100 guesses or so is kind of fine, unless the attacker knows you and has good guesses about your password.
Let's be generous and assume a six character password of all lowercase letters. That's 26^6 possible passwords. That's 3x10^8 possible passwords.
3 guesses means that you have a 0.000001% chance of guessing the password, whereas 10 guesses means your chances are 0.0000032%. Are you worried about a 0.0000022% difference?
The odds are slightly scarier if you limit it to English words, but I still doubt that 3 vs. 10 has any meaningful difference in practical terms.
I'm not seeing why 10 is so significantly worse than 3... How big of a difference is that, really? I believe it took something like 6 failed attempts for my bank to lock me out.
But why change the default? Is this in the top 10 things you would do after installing your distro of choice?
To me, this indicates a lack of judgement around what should be prioritised, which is reflected across the many issues the post raises. Naturally judgement is an acquired skill, which novices lack (and which they gain through experience and guidance), but given the big names associated with the project, that doesn't reflect well on their other projects.
> lol Are you saying that a distro that makes this kind of claim shouldn't be concerned with the amount of times you can type in a wrong password?
I will absolutely say that a distro making that claim should not worry about the difference between 3 and 10 password attempts on sudo (i.e. when you're already logged in).
> Especially since it's not vetting that actual security of the password itself?
Yes, that should be fixed. But it's a separate matter.
At this scale? No, no they do not. Even if you know my password is a single dictionary word in lower case, the odds of you guessing it in 3 vs 10 guesses is negligible.
In fact, let's do this right now: I've just thought of a random english word and written it down. I'll give you 20 guesses. Guess it right and I'll agree with you.
"Hey guys, I'm going to prove that an OS that claims that you don't have to worry about security anymore is actually secure by asking a total stranger to guess my password"
Since it's so flimsy and insecure, you should guess so you can prove how insecure it is. Alternatively, you could fail to do that, because 10 guesses is safe even against an awful password.
lol But what if, and I know this sounds absolutely insane, the person who stole your laptop knows you and isn't a total stranger on the internet? In your security guru mind, would that effect the probability of them guessing right? Or are you of the opinion that you don't need to worry about people close to you breaking into your stuff?
If someone steals your laptop, then sudo limiting guesses is completely irrelevant. Note that I started with
> I will absolutely say that a distro making that claim should not worry about the difference between 3 and 10 password attempts on sudo (i.e. when you're already logged in).
If you'd like to point out that it's really important to require a high-entropy password for the lockscreen or disk encryption, then I'll agree, but that isn't the argument we're in right now.
> The simplicity and efficiency of Visual Basic UI programming relied on several assumptions that became obsolete in 2000
This is a great point that extends beyond rebutting the rose-colored glasses for the gool ole days of programming. While yes, things were simpler. That simplicity came at a cost. For instance, how accessible were VB apps to people who had sight-related disabilities?
> how accessible were VB apps to people who had sight-related disabilities?
Coincidentally, they were very accessible because they used corresponding Win32 components for all logical UI entities, despite being fixed in layout. Therefore, they worked really well with screen readers.
Sadly, this is not the case with UI frameworks, which render the screen as a Vulcan/DirectX/OpenGL canvas. By the way, for today's Electron-based apps, you can use WAI-ARIA (or similar) standards to achieve a similar level of accessibility.
And to add to that, because some people might not know or have forgotten, colors where easily adjustable in winforms, so dark mode, high contrast mode, green, blue, hot pink etc. were all easily adjustable for all these apps and back in th day that was pretty standard to do for visually impaired people.
No extra work from programmers was necessary, so vastly superior to today where you have to beg for good dark mode support.
"Dark mode" today is the biggest scam - selling us a neutered form of color schemes that used to be a standard feature of any UI toolkit as something new and exciting.
> Literally anything that matters is going to get implemented in a crontrolled workflow that strips out all the autonomy with human checkpoint at every step.
Yea, there aren't a ton of problems (that I can see) in my current domain that could be solved by having unattended agents generating something.
I work in healthcare and there are a billion use cases right now, but none that don't require strict supervision. For instance, having an LLM processing history and physicals from potential referrals looking for patient problems/extracting historical information is cool, but it's nowhere near reliable enough to do anything but present that info back to the clinician to have them verify it.
Amen.
I am a CTO, but spend most of my day coding. I was brought onto a smallish/medium sized company to get their base tech into the modern age, build LOB apps to improve some workflows, and ultimate build a new EMR in that space to replace the one the company is using.
I don't have anybody that reports to me. I'm one of 2 tech people in a company of clinicians and doctors. There is no budgeting or reports I have to generate.
But, it was the only title that made sense given my role in that specific company.
Anytime someone asks me I always have to add "but I don't really do CTO things".
reply