Threads for frankzinger
-
The password manager I use (pass) has a really simple and widely supported ‘backup’ mechanism built in (git).
-
One downside of pass that I don’t see being talked about much is that the key names are not encrypted. This leaks a bit of metadata. Other than that’s it’s pretty much perfect for me.
https://github.com/gopasspw/gopass is also quite good, uses the same storage as
passand adds a few interesting features like git auto-syncing and browser integration.-
For the issue of having your names unencrypted, I came with the following idea for
safe, which could also work withpassor similar secret keepers:When syncing your secrets online, you can obfuscate the whole directory renaming all your entries after their sha256’d names, and store the conversion in a new secret, say “
hashmap”. Your directory structure is then totally unreadable, unless you have the key to read the secrets themselves.
I like this approach, because your safe protects itself. Here is my implementation (again, usingsafeas a backend):#!/bin/sh ORIG=$HOME/.secrets HASH=$HOME/.hashes # Create a new vault with the same master password mkdir -p $HASH cp $ORIG/master $HASH # Copy all secret in new vault, using their hashed names as key for p in $(find $ORIG -type f | grep -v /master$); do n="${p##$ORIG/}" h=$(echo $n | openssl sha256 | cut -d' ' -f2) cp $p "$HASH/$h" # print "HASH NAME" for the hashmap printf '%s\t%s\n' "$h" "$n" done | safe -s $HASH -a hashmapNote: the hash is the one of the entry name, not the password itself of course ;)
Then you end up with a password store like the following, which you can store in plain sight over git or whatever:
.hashes/master .hashes/hashmap .hashes/455f66d5e5f75ec1334127d73a3479b7a66c69ef4cc094e28def2075cc731035 .hashes/d3eb539a556352f3f47881d71fb0e5777b2f3e9a4251d283c18c67ce996774b7 .hashes/98623d38989a6957ec74319dc4552480fa3d96a59c5ffcac76c0e080d3940406 .hashes/df58574b01c57710a70ba201df6b5fb8dc0bf3906b8bf39f622936f92e6ffec7And when you want to de-obfuscate it, you can decrypt the secret “
hashmap”, and used that to rename your entries:$ safe -s ~/.hashes "hashmap" 455f66d5e5f75ec1334127d73a3479b7a66c69ef4cc094e28def2075cc731035 dedup.key d3eb539a556352f3f47881d71fb0e5777b2f3e9a4251d283c18c67ce996774b7 dummy 98623d38989a6957ec74319dc4552480fa3d96a59c5ffcac76c0e080d3940406 token/gitlab df58574b01c57710a70ba201df6b5fb8dc0bf3906b8bf39f622936f92e6ffec7 switch -
Yeah this downside bothers me a lot and it felt I’m pretty much alone in that. It’s what prevented me from using
passfor ages.I’d made the switch eventually and I’m really happy with it, but I had to add an the name obfuscation myself. The “unix philosophy” of pass is great because you can actually build stuff on top of it.
-
-
Every time I see
passcome up, it’s not long before someone mentions that the names of passwords aren’t kept secret. This seems like the most frequently mentioned and most severe downside ofpass. So I’m not sure that it isn’t talked about much.I do personally use
passand I do it in spite of the names being leaked. My threat model isn’t particularly sophisticated, so I’m generally okay with hiding the names simply by not sharing the repo.
-
-
-
-
Note that git use is optional. My ‘pass’ passwords are backed up daily along with the rest of the important files in my home directory, no extra work required as they’re just GPG-encrypted text files.
-
Came here to say the same thing. My backup of my
passrepo is a) it’s on every device I use and b) gets synced monthly to my off-site backup drive. If I lose the encryption key I’m in trouble, but I back that up, too.Using 2 password managers seems like a strange solution to me.
-
I switched from
passto KeePassXC a while ago. I use Syncthing to get the DB to my phone for use with KeePassDX and encrypted backups are automatically taken overnight with borg.Recommending two password managers is a little odd, I agree, but he does bring up a good point that everything is fallible and multiple backups are a good thing to have.
-
Eh, it’s 2 applications reading the same file format. Calling them 2 password managers would be the same as using 1password on 2 platforms, I don’t even see that worth mentioning.
FWIW, I also use KeepassXC on Linux+Windows, and Keepass2Android on Android, and Syncthing. I only sync down to my phone like once a month, and it works beautifully.
-
-
If I lose the encryption key I’m in trouble, but I back that up, too.
I use gopass, which allows for multiple encryption keys for the same password store. This is very useful in the case of losing access to one of them, or the intended purpose, having multiple users of the same store.
-
-
The unfortunate issue with
passis that when it uses git to back itself up, you still need a way to backup your GPG key, which is of course incompatible with git. Even if your GPG key is encrypted, I doubt you’d want to publish it online. So in order to backup your password manager, you must come up with 2 different backup medium, which means twice as much possibilities to lock yourself out.Also, managing a GPG keyring can have a lot of problems on its own on a daily usage basis (using a device without your keys, syncing keys, …). On this topic, using password managers based on a master password can help a lot.
-
Those are all good points. Since I use GPG for basically everything else (signing commits, communication, etc), the work to back that up I don’t really consider it to be part of the ‘backup my password manager’ activity.
The beauty of pass is that the storage mechanism is just a bunch of flat text files. Back them up however you want, you don’t have to use git (but it is nice that git support is built in).
I doubt you’d want to publish it online
Who said anything about it being public? Private git repos exist, either self hosted or with some paid service.
-
When you use GPG on a daily basis for other stuff, this would make more sense indeed. It is not my case though, so it bothered me a lot. So much that I ended up writing my own to mirror “
pass” usage but with a master password. The cool stuff about it is that I can now store my GPG key inside my secret manager 😉You’re right about private repos indeed, I think making it private makes it more complex to use git to sync it across devices. It makes for a good backup anyway as you said ! The flat file structure is great, and the composability of the tool makes it a breeze to obfuscate, backup, convert or integrate to any workflow !
-
I think making it private makes it more complex to use git to sync it across devices.
Not that complex, but yes, you now have to use either password or key auth to access it. And keep track of that, etc. The main thing I like about this setup is that it’s made from several simple components. Any of which could be replaced without affecting the others (or affecting them enough to require significant changes). And the architecture is simple enough for me to understand it without having to trust some external entity to always do the right thing and not break.
-
-
-
-
-
I would implement this with C++, where it’s a trivial RAII class with some macros as syntactic sugar.
Then it’s just a matter of compiling your C code as C++ with a compiler flag. You can still write in C, you just have access to more features if you want them.
-
-
I wrote about this on reddit.
-
-
But then your compile times will be inflated by a factor of 10.
-
-
-
-
-
Compile speed is one of my largest complains about Rust. These are good improvements but it’s still so far from where I’d like it. :(
My tonic/tower/tokio project with ~300 LOC takes about 3 minutes to build if I touch one leaf file not referenced elsewhere. The equivalent in Go would take less than 1 minute. My project is still tiny, I worry about what happens in 2, 3, 5 years. I work with C++ that takes over an hour for a full rebuild, but even touching just one file compiles and links quicker than my 300LOC Rust binary.
-
-
-
~300 LOC takes about 3 minutes to build if I touch one leaf file not referenced elsewhere.
Is this common? I didn’t realise Rust was that much slower than C++.
-
This is not only the compiler. Some ecosystems rely extremely on generics for modularity. Those are rolled out and compiled the moment all generic parameters are resolved, which is often delayed to the final program. This also leads to a lot of code being rolled out and optimised by the LLVM. Touching that program will lead to all that code being rolled out again.
Tools like cargo-bloat can show that effect.
rustc is not fast, but not that slow. But if you are actively asking for it to do a lot of work, you will get it.
This is, btw., one of the reasons I’m not using the tokio stack.
-
And to clarify for those not well versed in Rust, the problem with generics is only for functions/types that must be monomorphized. Rust gives you the option of choosing between monomorphized generics and VTable generics. The former often give better runtime performance at the cost of compile times. Libraries that use monomorphized generics heavily can dramatically degrade compile times, similar to how template heavy C++ has poor compile times.
-
Touching that program will lead to all that code being rolled out again.
Sure, but only for the touched file’s compilation unit, right? So it’s that and linking the executable that takes 3 minutes.
I have a template-heavy (stdlib and my own) C++ project here, consisting of multiple libs and executables and ~60,000 lines of C++ which all compiles and links from scratch in just over 4min on a computer from 2011. There’s a huge difference between that and a 300LOC program which takes 3min to do an incremental build.
Edit: excluded test LOC because I didn’t compile those when I timed the build.
Edit2: I guess this is really all moot because I’m sure there are benchmarks comparing apples to apples but even so, 300LOC is just tiny which is why I am so surprised.
-
It’s 300 LOC but using a lot of libraries, it may end up being 60k LOC in the end. The big difference is it’s 300 LOC with tens of thousands of essentially heavy template code underneath. It’s also only using ld, lld apparently speeds this up massively, and there’s seemingly plans to migrate rustc that direction. I’m also running it via WSL2, so I’m going to look at how it differs natively.
-
It’s 300 LOC but using a lot of libraries, it may end up being 60k LOC in the end.
I was actually compiling 60KLOC from scratch though. And that 60K uses lots of third-party templates. If I included third-party templates I would have much more than 60KLOC!
I’m also running it via WSL2, so I’m going to look at how it differs natively.
This sounds like it might make a difference.
-
-
-
-
-
-
I think that’s a reasonable rational and I wonder if DoH is going to end up being OS supported at some point.
-
-
What? How would providing a DoH at an OS level centralize anything more than providing dns over tcp?
Edit: It occurs to me that perhaps you thought I meant dns over https (DoH) as is implemented by firefox, ie with cloudflare being the defacto resolver. What I meant was that I wonder if DoH might come to be provided as a an alternative to or super set of normal OS DNS support with some sort of resolver discovery.
-
-
DoH/DoT don’t inherently require CAs. The OS could offer an interface like “set IP address and expected certificate in resolv.conf”, for example. (but, IMO, concerns about CAs are silly. Everything in userspace WILL use CAs, why would an OS take a hard stance against CAs?)
-
-
-
-
-
-
-
-
No, it’s TLS.
-
-
-
-
Primarily UDP, but TCP if the response it too large and EDNS is not supported; also for zone transfers.
-
-
-
-
-
-
-
-
-
I do this with Emacs and org-mode. I have one dedicated file -
journal.org, and I create an entry per day. Despite ‘setup’ and configuration costs (which isn’t really that bad if you look at getting started with Spacemacs or Doom-Emacs), I’ve yet to come across anything that’s as frictionless whilst at the same time retaining the ultimate in flexibility.It might be worth a look at org-journal, but personally I’ve found the above to be pretty much all I need.
-
Another +1 for org-mode. I keep an
inbox.orgthat has a top level heading for each day. So it might look something like this.* March 19 - Tuesday ** 1:1 w/ boss - some 1:1 notes - more notes *** TODO a task from the 1:1 ** A coding task [ 0 / 3 ] - [ ] write the code - [ ] write the tests - [ ] make a PRorg-mode has built in tools to manage the TODO items and the checkboxes for you. You can pull a list of all todos, or see what things were checked off what days. The check boxes give a nice overview when the subtasks are folded. All of this gets folded up by org-mode so I can see a nice summary of the day without needing to dig into each sub item.
-
org-mode has built in tools to manage the TODO items and the checkboxes for you.
The dates, too: ‘C-c .’ AKA ‘org-time-stamp’ inserts <2019-03-19 Tue> and S-leftarrow goes back one day, etc.
-
-
-
Same here with org-mode, but I also have a capture template that allows me to create a journal entry from anywhere with very little effort.
The following in my emacs config file allows me to type
C-c c jto open a buffer where I can record my entry, which then gets saved to~/org/journal.orgunder theJournalheading.(global-set-key (kbd "C-c c") 'org-capture) (setq org-capture-templates '(("j" "Journal" entry (file+olp+datetree "~/org/journal.org" "Journal") "* %?\n %i\n %a\n"))) -
I do this as well. I have a file: labbook.org with one entry per day. For me I was getting lost trying to come up with good methods of organizing my content (todo.org, $project.org, $person.org) and finally decided to simplify with chronological ordering.
-
-
-
Because I came to realize that much of Org’s power, much like the rest of emacs’s power, is more than I need and ends up being a bright shiny distraction that I end up futzing with endlessly rather than actually getting work done :)
Plain old Markdown files have served me very well for work stuff, and Evernote for personal stuff.
-
-
-
-
After the recent announcement of the F5 purchase of NGINX we decided to move back to Lighttpd.
Would be interesting to know why instead of just a blog post which is basically an annotated lighthttpd configuration.
-
If history has taught us anything, the timeline will go a little something like this. New cool features will only be available in the commercial version, because $$. The license will change, because $$. Dead project.
And it’s indeed an annotated lighttpd configuration as this roughly a replication of the nginx config we were using and… the documentation of lighttpd isn’t that great. :/
-
The lighttpd documentation sucks. Or at least it did three years ago when https://raymii.org ran on it. Nginx is better, but still missing comprehensive examples. Apache is best, on the documentation font.
I wouldn’t move my entire site to another webserver anytime soon (it runs nginx) but for new deployments I regularly just use Apache. With 2.4 being much much faster and just doing everything you want, it being open source and not bound to a corporation helps.
-
Whatever works for you. We used to run our all websites on lighttpd, before the project stalled. So seemed a good idea to move back, before nginx frustration kicked in. :)
-
Im a bit confused. You’re worried about Nginx development stalling or going dead in the future. So, you switched to one that’s already stalled in the past? Seems like the same problem.
Also, I thought Nginx was open source. If it is, people wanting to improve it can contribute to and/or fork it. If not, the problem wouldn’t be the company.
-
The project is no longer stalled and if it stalls again going to move, again. Which open source project did well after the parent company got acquired?
-
I agree with you that there’s some risk after a big acquisition. I didnt know lighttpd was active again. That’s cool.
-
If it was still as dead as it was a couple of years ago I would have continued my search. :)
-
Well, thanks for the tip. I was collecting lightweight servers and services in C language to use for tests on analysis and testing tools later. Lwan was main one for web. Lighttpd seems like a decent one for higher-feature server. I read Nginx was a C++ app. That means I have less tooling to use on it unless I build a C++ to C compiler. That’s… not happening… ;)
-
nginx is 97% C with no C++ so you’re good.
-
Thanks for correction. What’s other 3%?
-
Mostly vim script with a tiny bit of ‘other’ (according to github so who knows how accurate that is).
-
Alright. I’ll probably run tools on both then.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
It’s a web proxy with a few other features, in at least 99% of all cases.
What cool new features are people using?
Like, reading a few books on the topic suggested to me that despite the neat things Nginx can do we only use a couple workhorses in our daily lives as webshits:
- Virtual hosts
- Static asset hosting
- Caching
- SSL/Let’s Encrypt
- Load balancing for upstream servers
- Route rewriting and redirecting
- Throttling/blacklisting/whitelisting
- Websocket stuff
Like, sure you can do streaming media, weird auth integration, mail, direct database access, and other stuff, but the vast majority of devs are using a default install or some Docker image. But the bread and butter features? Those aren’t going away.
If the concern is that new goofy features like QUIC or HTTP3 or whatever will only be available under a commercial license…maaaaaybe we should stop encouraging churn in protocols that work well enough?
It just seems like much ado about nothing to me.
-
maaaaaybe we should stop encouraging churn in protocols that work well enough?
They don’t work well enough on mobile networks. In particular, QUIC’s main advantage over TCP is it directly addresses the issues caused by TCP’s congestion-avoidance algorithm on links with rapidly fluctuating capacities. I share your concern that things seem like they’re changing faster than they were before, but it’s not because engineers are bored and have nothing better to do.
-
-
-
-
I can’t get past the apostrophe…
-
And it’s not a one-off, either:
By default, iPhone’s back these up to the cloud
-
-
-
Off-topic: is it just me or do all of the game screenshots look like they have a greyscale canvas filters applied?
-
-
-
If you’d like to dissuade people from gaming on FreeBSD I would leave it as-is.
-
-
-
-
Nice! I’ll have to make an Emacs template for when I first open a Makefile to insert that boilerplate. I’d also add the code to generate the header file dependency tree using the correct g++ flags.
-
-
On BSD:
depend: mkdep $(CFLAGS) $(SRCS) -
Better than this crufty make command I’ve been carrying around for probably 20 years!
MAKEDEPS=@echo Making $*.d; \ set -e; rm -f $@; \ $(CXX) -MM $(CXXFLAGS) $< > $@.$$$$; \ sed 's,\(.*$(*F)\)\.o[ :]*,$(*D)/\1.o $@ : ,g' < $@.$$$$ > $@; \ rm -f $@.$$$$ %.d: %.cpp $(MAKEDEPS)-
Make already gets such overwhelmingly negative press so let’s not leave this as-is lest others think this is how things have to be. Here is mine:
%.d: %.cpp $(CXX) -MM -MT "$(basename $@).d $(basename $@).o" $< > $@ -
-
-
-
-
I’m kind of speechless. This looks truly genuine, and it makes me hopeful for the Linux kernel community (and all the other open-source communities it influences!) in a way I hadn’t predicted would ever happen.
-
I feel quite the opposite. I think it’s very sad that the reddit/twitter bandwagon of people that never actually contribute anything to open source but love to rip those that do to shreds have finally go to him.
-
This argument is a classic to be found in all of those discussions, but doesn’t hold any water.
- Coraline Ada, the woman who’s work the now adopted Code of Conduct is based on, is the primary author of 25 Ruby gems, regular contributor, very welcome as a speaker in the Ruby world.
- Sage Sharp, known for their angry good-bye from the Linux kernel and outspoken critic of Linus, has been author and maintainer of the USB-3.0 implementation in the kernel. Sage also lead intern groups working on the Kernel through Outreachy.
- Matthew Garret, also a very outspoken critic, has been maintaining kernel power management modules and is constantly working on Linux related issues ever since.
The no-contribution Twitter crowd, right?
The list could go on and on. Find another angle, this one insults the intelligence of everyone at the discussion table. It only works if you don’t name names, if you do, you suddenly find that these people do contribute.
Finally, as someone managing a huge FOSS project with > 100 maintainers, I think this gatekeeping isn’t part of open standards. If your project is open and contribution is free to everyone, the barrier for criticising your projects methods and practices should be as low as the barrier for contributing anything else: as close to zero as possible. This is also important for practices to travel between projects.
-
And very recently, Alexander Popov, no lightweight by any measure. https://lwn.net/SubscriberLink/764325/09702eb949176f55/.
-
I’m sympathetic to Torvalds critique, if not his wording. It seems bizarre to just live with kernel code that uses uninitialized data structures and doesn’t cross check pointers and hope that some complex mechanism will ameliorate the problem.
-
Sure, his technical arguments were probably sound, as usual, but his abuse of Popov left the latter “emotionally dead for weeks”. Popov might’ve gotten the fixes made and thus the patch committed much sooner had Linus not abused him so the project also loses.
-
I am not convinced the patch ever became worthwhile - but I agree that Linus’s argument style was counterproductive and abusive.
-
-
-
-
I think you’ve got a selection bias in which criticism you’re seeing. From my perspective, the people who I hear take the most issue with Linus’s conduct are largely people who’ve quit kernel development as a result of it, or people with many years of OSS experience (such as myself).
-
I’m not an advocate of the absurdly excessive personal attacks for which Linus is known but at the same time I think quitting kernel development because of those personal attacks shows a lack of awareness of how OSS and specifically Linux operates. The reality is that Linux is Linus’s project and he’s incentivized to take your patches to make his project better, not to build a cooperative community. The community, if one could call it that, is incidental to Linus’s incentives.
If a person quits because of Linus’s behavior, it signals to me that their motivation had something to do with the approval of others and unfortunately those motivations are incompatible with Linux’s development process. Linus’s insults are just the tip of the iceberg when it comes to all the other problems that will arise due to the mismatched expectations. A famous example was when Ingo Molnar rewrote Con Konlivas’s CFS, or the multiple times grsecurity’s patches were rewritten by others.
Linus basically doesn’t owe anyone anything, and it’s not because he’s a jerk (though maybe he is), it’s because of the emergent social phenomena around OSS. Similarly, no one owes Linus anything. Many actors out there are using Linux to facilitate their billions of revenue and not paying Linus anything. If you write code and put it out there, there is no obligation that what you want to happen with it will happen, and it’s not unlikely that what happens with it will hurt your ego. If someone quits kernel development because of Linus’s behavior, they really should reexamine why they want to write OSS code in the first place and whether or not OSS development is the best way to reach their goals.
All that said I don’t necessarily disagree with Linus’s recent decision. It shows a conscious effort on his part to change the strategy used to sustain the project. I’m only criticizing those who may have mismatched expectations of the potential outcomes in OSS work.
-
The reality is that Linux is Linus’s project and he’s incentivized to take your patches to make his project better, not to build a cooperative community.
Linus is an employee of the Linux Foundations, a nonprofit corporation with stakeholders like Red Hat, Google, and Intel, and he owes his employers their money’s worth as much as anybody else who works for hire.
I would agree with you if this was still the Linux that wasn’t going to become a big thing like Hurd. But Linus chose to remain the project lead even as the job became less technical and more political, and when they decided to pay him to work on it full-time, he accepted. There’s money, there’s a trademark, and there’s inertia undermining any claim that the situation is totally voluntary and that nobody owes anybody anything.
And that’s before we even consider the fact that there is a huge and informal web of soft obligations because human beings don’t work the way you say they do.
-
Linus owns the trademark and even if he didn’t work for the Linux Foundation he would still be the maintainer of Linux. The entire development structure is centered on him. No company could successfully and sustainably fork Linux if Linus decided to operate against their goals.
I made no claim as to how human beings work. My claim is simply that OSS is essentially a free-for-all and those that aren’t acutely aware of that and incorrectly treat OSS like a traditional organization that has inbuilt obligations to their well-being will be inevitably burned. Linux is not a cathedral, it’s a bazaar. http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/
-
-
-
-
-
No I’m talking about the much larger crowd of people applauding him for ‘moderating himself’ and other such nonsense. I’m talking about the huge crowd of people that act like every message he sends is a scathing personal attack on someone for indenting something incorrectly.
-
Well, perhaps it’s just that our perception of the (ultimately utterly pointless) social media reactions is colored by our preconceptions. I’ve mostly seen people praise and defend him.
I’m not sure what the resistance is about. It seems to me that all these CoCs are just a way of codifying “don’t be an asshole”, and it’s perplexing that people get so angry about it. But it cannot be that, right? Surely you and others are not against “don’t be an asshole” as a work ethic?
If not that, then what? I’ve listened to Sam Harris quite a lot recently, so I have some feeling about the problem of identity politics et al, especially in the US. I’m just still not exactly convinced, because I don’t see it happening. Perhaps it’s not that big a problem in Europe?
-
I’m not sure what the resistance is about. It seems to me that all these CoCs are just a way of codifying “don’t be an asshole”, and it’s perplexing that people get so angry about it. But it cannot be that, right? Surely you and others are not against “don’t be an asshole” as a work ethic?
I think a lot of this is related to the “hacker identity” which is strongly tied up with counterculture, stepping outside/dismissing/rebelling against social conventions. For example, in the genre of cyberpunk (which I’d consider a hacker’s dream world, even if it’s a dystopia) there is almost no law and order or even anarchy, everyone does their own thing and your skill is the only thing that counts.
So I think a lot of the reaction is “who are you to come in and police the way we’ve always been doing things?”. I suppose a lot of these people claiming are seen as outside intruders enforcing their “outside” morals on the hacker “community” at alrge (if there is even such a thing). For this reason I think it’s important that people like Linus, who are truly regarded as being “from” the community, are signaling that change needs to come. We’re all human, not machines.
-
I think there are two big issues. One is that “hacker culture” has historically attracted people with social issues. I know that it appealed to me as an unpopular, nerdy, shy kid: I didn’t have a lot of outlets, so computers and the Internet helped me form my personality. That’s great; I don’t know where I’d be without it. That leads into the second issue, though, which is that it’s utterly dismissive of all the traditions we call the “humanities.” I am lucky, I think, in that I’ve always been “into” literature, philosophy, theology, and so on, and could balance my computer-nerddom with those fields. (In fact, my only college degree is a BA in English.) Without that tempering influence, it’s very easy to get caught up in an aspiration-to-Spock sort of behavioral cycle.
-
-
Surely you and others are not against “don’t be an asshole” as a work ethic?
Who defines what an ‘asshole’ is?
My problem is that Codes of Conduct explicitly and implicitly privelege some groups but not others for protection, and that even when de jure they protect some groups, de facto they do not.
Moreover, I find the idea that we should generally value social etiquette more than technical excellence to be troublesome. Are there people who are so socially rude that they should be shunned? Sure. But should shunning be our go-to? I don’t think so.
-
-
It seems to me that all these CoCs are just a way of codifying “don’t be an asshole”, and it’s perplexing that people get so angry about it.
I can’t speak for all opponents, but for me at least I disagree with it being “codified”, or rather formalized what essentially isn’t formal. People contributing to software won’t just suddenly become good people because there is a CoC. It’s like wanting to prevent a husband from abusing his wife by requiring him to hold up his hands whenever they are in the same room.
What I usually fear from these kinds of things is that they one the one hand subvert genuine communities, customs and practices, while possibly encouraging the harmful parts of these communities to discreetly and dishonestly live on, much harder to fight or criticize. Essentially it’s taking a passive stance towards real issues people should actively and collectively oppose – say harassment or insulting people.
Turning issues of civility and decency into rules, especially if these are too vague, always bears the danger of being on the one hand abused by those trying to evade then (“oh, that’s not what I meant”) and on the other hand by those enforcing them (“rules are rules”)…
But then again, I’m not a Linux contributer (although I would be honored to managed to get there one day), and I can just hope it turns out well for them, and the issue doesn’t get instrumentalised.
-
People contributing to software won’t just suddenly become good people because there is a CoC. It’s like wanting to prevent a husband from abusing his wife by requiring him to hold up his hands whenever they are in the same room.
I find that analogy deeply flawed (and somewhat bizarre). The CoC doesn’t require anyone to do anything as ridiculous as hold their hands in the air while in the same room as their wife.
Essentially it’s taking a passive stance towards real issues people should actively and collectively oppose – say harassment or insulting people.
So you’re saying that rather than having a CoC it would be better if, every time Linus or some other kernel developer was offensive, other developers stepped in and told them off? How do you make that happen? Do you not think the CoC is a step towards making that happen?
-
The CoC doesn’t require anyone to do anything as ridiculous as hold their hands in the air while in the same room as their wife
Of course not literally, but for many people they have to adjust their own behavior in unusual (and often enough unknown) ways. I’ve experienced communities on the Internet which banned their users for using any phrase that has to do with eyesight disabilities (e.g “I can’t see what’s wrong”), and most people simply just didn’t know about this.
And the point of my analogy still remains, the issue with the husband beating his wife isn’t that he can but that he wants to, consciously or unconsciously. Just saying “Don’t” won’t help solve the problems in the long term, just suppresses them.
So you’re saying that rather than having a CoC it would be better if, every time Linus or some other kernel developer was offensive, other developers stepped in and told them off?
The way I see it, this would obviously be better. This means that the community has a strong sense of internal solidarity and openness that they manage to enforce by their own means. Essentially this means that the goals of the CoC come naturally and authentically to the members.
How do you make that happen? Do you not think the CoC is a step towards making that happen?
I really can’t say, nor do I know. Nothing I’m saying is authoritative or really substantial, I’m just trying to give a more reasonable criticism of codes of conducts than certain other people in this thread.
-
Just saying “Don’t” won’t help solve the problems in the long term, just suppresses them.
Suppressing the problem does help, though. I don’t want to continue the husband/wife analogy as I find it distasteful, but once you establish norms of good (or at least better) behaviour, people do adjust. And by having the CoC, even though it doesn’t cover every case, it sets up some basic guidelines about what will and won’t be accepted - so you remove the excuse of “no this is fine, everyone talks this way, deal with it” from the outset. This alone can make people who otherwise feel vulnerable, and/or belong to marginalised groups etc, to feel more comfortable.
I’d prefer we didn’t need CoCs, but clearly we need something to make development groups less unpleasant to participate in. And even if you don’t think they’re effective, I can’t see how they hurt.
-
I guess we just have different views on the question if issues are to be addressed or suppressed (in my eyes willfully ignored). But that’s fine. There’s more I could say, but I won’t for the sake of brevity, except that a CoC should (imo) be always the last resort when everything else has failed. A kind of martial law. Since they aren’t just guidelines or tips, but can justify very drastic behavior.
-
I guess we just have different views on the question if issues are to be addressed or suppressed
I think that’s a mis-characterization. We both seem to think that offensive behaviour should be addressed by other people stepping in as appropriate, but I see the CoC as prompting this to happen, whereas you are saying that you don’t know how to make it happen and that the existence of a CoC will make people suppress their bad behaviour and that this is bad (for some reason which I’m not clear on).
I would say that the existence of a CoC may make people suppress an urge to spout off an offensive rant against another developer, and that’s a good thing. I also think that it lends a stronger position to anyone who does step in when offensive behaviour does occur (despite the existence of the CoC). I think it’s more likely that, rather than completely suppressing offensive behaviour, the CoC causes more people to respond and challenge such behaviour, which is the outcome that we both seem to think is ideal (and which leads to less of the behaviour occurring in future). Now if you disagree that the CoC will lead to that happening, that’s fine, but:
A kind of martial law. Since they aren’t just guidelines or tips, but can justify very drastic behavior.
That’s just ridiculous. A CoC is nothing like martial law. The only behaviour it justifies is that of stepping in to control other, offensive, behaviour:
… to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.
Maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project’s leadership.
These are the only behaviours that are actually “justified”, to use your word, rather than expressly prohibited, by the CoC. I think saying these are “drastic” and comparing to martial law is clearly an immense level of exaggeration.
-
but I see the CoC as prompting this to happen, whereas you are saying that you don’t know how to make it happen and that the existence of a CoC will make people suppress their bad behaviour and that this is bad (for some reason which I’m not clear on).
I don’t want this to go on for too long, so I’ll just quickly clarify my two main points:
- banning obvious misbehavior won’t change people, it will at best make them be quiet, at worst invite them to a passive aggressive game of trying to evade the rules while still trying to be mean or hurtful.
- a CoC is a principally passive stance, where active action is necessary trying to address and resolve issues. Suppressing discussion where necessary may (again) lead to a overall harmful atmosphere, especially towards those not used to these, usually American, norms (because of different backgrounds, cultures, standards).
So it’s not that it’s irrelevant, but that it may go wrong, specifically when applied to quickly or without introduction. But again, maybe not.
A CoC is nothing like martial law.
You’re right, I should have put “martial law” in quotes. My point is that it shouldn’t be a permanent solution, but as you said try to push a community in a better direction, “stabilize” a situation so to speak. Even here between us we see how different background, invoke different images and connotations with examples as simple as metaphors.
-
You’re right, I should have put “martial law” in quotes. My point is that it shouldn’t be a permanent solution
Ok, I understand now what you meant.
banning obvious misbehavior won’t change people
I am not sure that I agree with this. For one thing, “obvious misbehaviour” may be generally understood but is not obvious to everyone. You will see many people arguing that Linus’ rants are perfectly acceptable, for various reasons. By making a clear statement that “behaviour X is wrong” you are removing the doubt.
at worst invite them to a passive aggressive game of trying to evade the rules while still trying to be mean or hurtful
I believe that the Contributors’ Covenant deliberately avoids trying to produce an exhaustive list of disallowed behaviour, precisely so that the rules can’t be avoided in this way. Yes, there will always be some problematic individuals who push the limits regardless. But is it better that they are at least constrained in this way, rather than being able to be openly offensive? I think so. And I think this anyway is somewhat irrelevant to the issue of a CoC; even if you generally enforce good behaviour without a CoC, there can always be trouble-makers who test the limits.
a CoC is a principally passive stance, where active action is necessary trying to address and resolve issues. Suppressing discussion where necessary may (again) lead to a overall harmful atmosphere
A CoC is just a document, so it is passive in that sense, yes. But it doesn’t prevent any affirmative action - it encourages it.
What this seems to boil down to, if I’m reading you correctly, is that you’re saying that it’s better to allow offensive behaviour to occur - and then to have the perpetrator reprimanded - than it is to document what is considered offensive behaviour so that it will be deliberately avoided. I cannot see how that is better. If someone’s response to a rule is to try to find underhanded ways to work around that rule, what difference does it make whether the rule is written down or enforced only by-the-way?
-
For one thing, “obvious misbehaviour” may be generally understood but is not obvious to everyone. You will see many people arguing that Linus’ rants are perfectly acceptable, for various reasons.
Ok, but these people would say these rants are good because they are brutal or some kind of “not nice”. Nobody, or at least nobody I’ve seen, claims that Linus is always “kind” and “civil” and people are just misunderstanding him.
Yes, there will always be some problematic individuals who push the limits regardless. But is it better that they are at least constrained in this way, rather than being able to be openly offensive? I think so. And I think this anyway is somewhat irrelevant to the issue of a CoC; even if you generally enforce good behaviour without a CoC, there can always be trouble-makers who test the limits.
I get your point. I still belive there to be a difference between the two cases – maybe not immediately visible, but on a more symbolic level. In the first case the trouble-maker stands in conflict with the (official, formal) document and will try to defend his or her behavior on semantic issues and misreadings, while in the second case the conflict is more direct with the “community”. This is not to say that no rules should be made or no behavior should be sanctioned – just that in the long term this should be a internal and organic (eg. self-made (maybe even unofficial) “community guidelines”, that serve to introduce new members) process not ordained from above.
you’re saying that it’s better to allow offensive behaviour to occur - and then to have the perpetrator reprimanded - than it is to document what is considered offensive behaviour so that it will be deliberately avoided
I wouln’t phrase it that way, since to me many of these terms are too vague. Anyways, in my eyes this seems to be unrelated to CoC: from my experience most people encounter a CoC not by reading it before they do anything, but by people using it as “legislation” – they make a mistake and are then banned and excluded – often enough permanently because it’s just the easiest thing for moderators to do. Either way, the “offensive act” has taken place – with a quick and formal process leading to confusion on the one side and a honest attempt to point out what a person has done (on a case-to-case basis) in the other.
-
For one thing, “obvious misbehaviour” may be generally understood but is not obvious to everyone. You will see many people arguing that Linus’ rants are perfectly acceptable, for various reasons.
Ok, but these people would say these rants are good because they are brutal or some kind of “not nice”. Nobody, or at least nobody I’ve seen, claims that Linus is always “kind” and “civil” and people are just misunderstanding him.
That’s my point. The CoC makes it clear that we are expected to be civil. Therefore if anyone goes on an uncivil rant, you can’t claim that it’s ok because [whatever reason], as it’s been explicitly stated that it’s not acceptable. You’re making the community rules about what certain unacceptable behaviour explicit, and removing the inevitable and fruitless debates over whether it’s ok to swear at someone for submitting a bad patch etc.
Whereas now, people don’t understand that it’s not ok to be uncivil.
Either way, the “offensive act” has taken place – with a quick and formal process leading to confusion on the one side and a honest attempt to point out what a person has done (on a case-to-case basis) in the other.
Other than anecdotal examples where it may have been the case with some unknown number of other projects (links to relevant mailing list posts would be interesting to see), I don’t see any evidence that a CoC will necessarily lead to confusion nor to people being wantonly banned from participating for one-off infractions; I certainly don’t think it’s designed or intended for that.
-
-
-
-
-
-
I’ve experienced communities on the Internet which banned their users for using any phrase that has to do with eyesight disabilities (e.g “I can’t see what’s wrong”), and most people simply just didn’t know about this.
As a visually impaired person with several friends who are totally blind, this strikes me as ridiculous. I have no problem with such everyday use of “see” and related words. I think my blind friends would agree.
-
-
-
-
-
What’s so bad about people in positions of power to stop being abusive? Isn’t it something to applaud?
-
-
-
-
-
-
I enjoyed the author’s previous series of articles on C++, but I found this one pretty vacuous. I think my only advice to readers of this article would be to make up your own mind about which languages to learn and use, or find some other source to help you make up your mind. You very well might wind up agreeing with the OP:
Programmers spend a lot of time fighting the borrow checker and other language rules in order to placate the compiler that their code really is safe.
But it is not true for a lot of people writing Rust, myself included. Don’t take the above as a fact that must be true. Cognitive overheads come in many shapes and sizes, and not all of them are equal for all people.
A better version of this article might have went out and collected evidence, such as examples of actual work done or experience reports or a real comparison of something. It would have been a lot more work, but it wouldn’t have been vacuous and might have actually helped someone answer the question posed by the OP.
Both Go and Rust decided to special case their map implementations.
Rust did not special case its “map implementation.” Rust, the language, doesn’t have a map.
-
Hi burntsushi - sorry you did not like it. I spent months before this article asking Rust developers about their experiences where I concentrated on people actually shipping code. I found a lot of frustration among the production programmers, less so among the people who enjoy challenging puzzles. They mostly like the constraints and in fact find it rewarding to fit their code within them. I did not write this sentence without making sure it at least reflected the experience of a lot of people.
-
I would expect an article on the experience reports of production users to have quite a bit of nuance, but your article is mostly written in a binary style without much room for nuance at all. This does not reflect my understanding of reality at all—not just with Rust but with anything. So it’s kind of hard for me to trust that your characterizations are actually useful.
I realize we’re probably at an impasse here and there’s nothing to be done. Personally, I think the style of article you were trying to write is incredibly hard to do so successfully. But there are some pretty glaring errors here, of which lack of nuance and actual evidence are the biggest ones. There’s a lot of certainty expressed in this article on your behalf, which makes me extremely skeptical by nature.
(FWIW, I like Rust. I ship Rust code in production, at both my job and in open source. And I am not a huge fan of puzzles, much to the frustration of my wife, who loves them.)
-
I just wanted to say I thought your article was excellent and well reasoned. A lot of people here seem to find your points controversial but as someone who programs C++ for food, Go for fun and Rust out of interest I thought your assessment was fair.
Lobsters (and Hacker News) seem to be very favourable to Rust at the moment and that’s fine. Rust has a lot to offer. However my experience has been similar to yours: the Rust community can sometimes be tiresome and Rust itself can involve a lot of “wrestling with the compiler” as Jonathan Turner himself said. Rust also provides some amazing memory safety features which I think are a great contribution so there are pluses and minuses.
Language design is all about trade-offs and I think it’s up to us all to decide what we value in a language. The “one language fits all” evangelists seem to be ignoring that every language has strong points and weak points. There’s no one true language and there never can be since each of the hundreds of language design decisions involved in designing a language sacrifices one benefit in favour of another. It’s all about the trade-offs, and that’s why each language has its place in the world.
-
I found the article unreasonable because I disagree on two facts: that you can write safe C (and C++), and that you can’t write Rust with fun. Interpreted reasonably (so for example, excluding formally verified C in seL4, etc.), it seems to me people are demonstrably incapable of writing safe C (and C++), and people are demonstrably capable of writing Rust with fun. I am curious about your opinion of these two statements.
-
I think you’re making a straw man argument here: he never said you can’t have fun with Rust. By changing his statement into an absolute you’ve changed the meaning. What he said was “Rust is not a particularly fun language to use (unless you like puzzles).” That’s obviously a subjective statement of his personal experience so it’s not something you can falsify. And he did say up front “I am very biased towards C++” so it’s not like he was pretending to be impartial or express anything other than his opinion here.
Your other point “people are demonstrably incapable writing safe C” is similarly plagued by absolute phrasing. People have demonstrably used unsafe constructs in Rust and created memory safety bugs so if we’re living in a world of such absolute statements then you’d have to admit that the exact same statement applies to Rust.
A much more moderate reality is that Rust helps somewhat with one particular class of bugs - which is great. It doesn’t entirely fix the problem because unsafe access is still needed for some things. C++ from C++11 onwards also solves quite a lot (but not all) of the same memory safety issues as long as you choose to avoid the unsafe constructs, just like in Rust.
An alternative statement of “people can choose to write safe Rust by avoiding unsafe constructs” is probably matched these days with “people can choose to write safe C++17 by avoiding unsafe constructs”… And that’s pretty much what any decent C++ shop is doing these days.
-
somewhat with one particular class of bugs
It helps with several types of bugs that often lead to crashes or code injections in C. We call the collective result of addressing them “memory safety.” The extra ability to prevent classes of temporal errors… easy-to-create, hard-to-find errors in other languages… without a GC was major development. Saying “one class” makes it seem like Rust is knocking out one type of bug instead of piles of them that regularly hit C programs written by experienced coders.
An alternative statement of “people can choose to write safe Rust by avoiding unsafe constructs” is probably matched these days with “people can choose to write safe C++17 by avoiding unsafe constructs”
Maybe. I’m not familiar with C++17 enough to know. I know C++ was built on top of unsafe language with Rust designed ground-up to be safe-as-possible by default. I caution people to look very carefully for ways to do C++17 unsafely before thinking it’s equivalent to what safe Rust is doing.
-
-
-
-
-
I agree wholeheartedly. Not sure who the target survey group was for Rust but I’d be interested to better understand the questions posed.
Having written a pretty large amount of Rust that now runs in production on some pretty big systems, I don’t find I’m “fighting” the compiler. You might fight it a bit at the beginning in the sense that you’re learning a new language and a new way of thinking. This is much like learning to use Haskell. It isn’t a good or bad thing, it’s simply a different thing.
For context for the author - I’ve got 10 years of professional C++ experience at a large software engineering company. Unless you have a considerable amount of legacy C++ to integrate with or an esoteric platform to support, I really don’t see a reason to start a new project in C++. The number of times Rust has saved my bacon in catching a subtle cross-thread variable sharing issue or enforcing some strong requirements around the borrow checker have saved me many hours of debugging.
-
I really don’t see a reason to start a new project in C++.
Here’s one: there’s simply not enough lines of Rust code running in production to convince me to write a big project in it right now. v1.0 was released 3 or 4 years ago; C++ in 1983 or something. I believe you when you tell me Rust solves most memory-safety issues, but there’s a lot more to a language than that. Rust has a lot to prove (and I truly hope that it will, one day).
-
-
-
-
They [TrueType fonts] look ugly in my opinion and rendering of these is slower (you can measure it).
It’s true they render slower. I have never found it to be a problem. (And I don’t get the author’s deep affection for the Terminus font.)
-
It is strange, taste in fonts. I’ve searched for a different programming/terminal font a few times but Terminus looks best to me.
-
-
-
So far I’ve only found one solution that is actually robust. Which is to manually check that the value is not nil before actually using it.
This seems reasonable to me. If anything, I’d consider knowing how and when to use this kind of check a part of language competency knowledge as it is how Go was designed.
-
We expect people to be competent enough to not crash their cars, but we still put seatbelts in.
That’s perhaps a bad analogy, because most people would say that there are scenarios where you being involved in a car crash wasn’t your fault. (My former driver’s ed teacher would disagree, but that’s another post.) However, the point remains that mistakes happen, and can remain undiscovered for a disturbingly long period of time. Putting it all down to competence is counter to what we’ve learned about what happens with software projects, whether we want it to happen or not.
-
I wish more languages had patterns. Haskell example:
data Named = Named {Name :: Text} deriving Show greeting :: Maybe Named -> Text greeting (Just thing) = "Hello " + (Name thing) greeting _ = ""You still have to implement each pattern, but it’s so much easier, especially since the compiler will warn you when you miss one.
-
-
-
-
It’s in the standard library now so I think it’s integral.
-
If it’s not returned as a rule and not as an exception throughout the standard library it doesn’t matter though. C++, both the stdlib and the wider ecosystem, rely primarily on error handling outside of the type-system, as do many languages with even more integrated Maybe types
-
-
-
-
Yep. Swift has
nil, and by default no type can hold a nil. You have to annotate them with?(or!if you just don’t care, see below).var x: Int = nil // error var x: Int? = nil // okIt’s unwrapped with either
if letorguard letif let unwrapped_x = x { print("x is \(x)") } else { print("x was nil") } guard let unwrapped_x = x else { print("x was nil") return }Guardexpects that you leave the surrounding block if the check fails.You can also force the unwraps with
!.let x_str = "3" let x = Int(x_str)! // would crash at run-time if the conversion wouldn't succeedThen there’s implicit unwraps, which are pretty much like Java objects in the sense that if the object is
nilwhen you try to use it, you get a run-time crash.let x: Int! = nil
-
-
-
Hey, I’m the author of the post. And indeed that does work, which is why I’m doing that currently. However, like I try to explain further in the post this has quite some downsides. The main one is that it can be easily forgotten. The worst part of which is that if you did forget, you will likely find out only by a runtime panic. Which if you have some bad luck will occur in production. The point I try to make is that it would be nice to have this be a compile time failure.
-
-
-
Last week and this one:
- Got my motorcycle running by jumping it. The Clymer manual’s troubleshooting steps were wrong; f you haven’t used a Clymer manual, this is a shocking betrayal. Now waiting for April showers to go away so I can ride more; I feel like seasonal lag in Chicago has increased by 2-3 weeks over the last 30 years I’ve lived in Chicago, but will probably never make the time to research this.
- Formed my LLC for the TBA project. This week I’m testing the three key tools and prototyping my integrating code.
- Met with a potential client, very unlikely to come to anything. Contacted out of the blue with an excellent opportunity I am cautiously optimistic for.
- Migrated from irssi to WeeChat as the Slack IRC gateway was disabled. (I thought I had to the end of the month, oops.) Now WeeChat handles my IRC, Slack, Twitter, and Fediverse chatting and I’m very impressed with WeeChat: great docs, a polished interface, meets all my needs. Minor win: merging buffers is great for tidying a dozen+ very quiet chatrooms; minor loss: bitlbee’s Twitter integration can’t follow saved searches, so I’ve lost useful alerting for my name, interesting conferences, and Lobsters.
- Didn’t redo the calendar, turns out radicale is Python and pip didn’t want to cooperate. Going with DAViCal instead. Bunch of other similar yak-shaving of tech setup.
- Finishing the Aubrey-Maturin series I started reading during my batch at Recurse Center. I’ve really enjoyed the period language, manners, and plotting and am sad to have reached the end. Probably going to read through Terry Pratchett next; I’ve only read Good Omens.
-
Finishing the Aubrey-Maturin series I started reading during my batch at Recurse Center. I’ve really enjoyed the period language, manners, and plotting and am sad to have reached the end.
Those truly are great books. Did you read the last (incomplete) one? I didn’t think it’d be worth it.
-
-
I am totally impressed by the article. The authors tries to silence his computers for decades, I am doing the exactly opposite. All my workstations in the past were equipped with large fans (not the small and noisy ones, the large ones that run slow) to generate a decent amount of white noise.
When I am usually sitting in my room and nothing is running, I can hear the noise from the trains, cars, kids, etc outside and from my neighbours inside the house. As soon as I turn my computer on the room is filled with white noise and I can concentrate on my work. Thus, I personally would never, ever use a silent workstation :)
Am I the only one using “noisy” computers?
-
-
-
I first tried listening to YouTube videos like speps mentioned and that got me interested. I had a shell alias for it named ‘pink’ that used sox, but I don’t seem to have it on the computer I’m currently using. I’m pretty sure it was just something like this:
$ play -n synth pinknoise vol 0.25I just start it up when I get too distracted. There’s also ‘brownnoise’ and (suprise) ‘whitenoise’. Listening to regular white noise first gives you something to compare it with. I find pink noise to sound kind of like flowing water and not at all distracting. You might be fine with the sound of your computer ;).
$ play -n synth brownnoise vol 0.25 $ play -n synth whitenoise vol 0.25Actually it might have been this one (sounds more like what I remember): https://askubuntu.com/a/789469
-
-
I use the iOS app from https://mynoise.net. It generates various types of noises and lets you change levels, save presets, etc. They also have albums on iTunes, Amazon, and Google Play. Most generators cost money but I find the free set to be good enough. Although it does “coloured noises” I prefer the “rain storm” generator.
-
-
-
-
While I agree that the article is probably true, the biggest problem with Electron, and a lot of modern software development, is that “Developer happiness” and “Developer Efficiency” are both arguments for electron, but “user happiness” and “user efficiency” aren’t.
Electron developers are incentivized to develop applications that make users happy in the small- they want something that looks nice, has lots of features, is engaging. The problem is that in their myopic pursuit of this one-and-only goal too many apps (and electron is a vanguard of this trend, but not the only culpable technology by far) forget that a user want’s to do things other than constantly interact with that one single application for their entire computing existence.
That’s where electron as a model breaks down. Electron apps are performant enough, and don’t use too much memory, when they are used by themselves on a desktop or powerful docked laptop- but I shouldn’t have to be killing slack and zoom every time I unplug my laptop from a power source because I know they’ll cut my battery life in half. I shouldn’t have to ration which slack teams I join lest I find other important processes swapping or getting oom-killed.
Even without those concerns, Electron apps selfishly break the consistency of visual design and metaphors used in a desktop experience, calling attention to themselves with unidiomatic designs.
We do need easier and better ways of developing cross-platform desktop applications. Qt seems to be the furthest along in this regard, but for reasons not entirely clear to me it’s never seemed to enter the wider developer consciousness - perhaps because of the licensing model, or perhaps because far fewer people talk about it than actually use it and so it’s never been the “new hotness”.
-
the author specifically calls out what the problem with QT is.
Native cross-platform solution like Qt tend to consider themselves more a library, less a platform, and have little to offer when it comes to creating auto-updating software, installers, and App Store packages.
Don’t be so dismissive of peoples choices with the ‘new hotness’ criticism.
-
I think you misunderstand what I’m saying. My claim isn’t that Qt would solve every problem that people are looking to electron to solve if only it were more popular. My claim is merely that of the cross-platform native toolkits, Qt seems to be both the furthest along in terms of capability, and also seems to be one of the less recognized tools in that space (compared to Wx, GTK, Mono, Unity, heck I’ve seen seen more about TK and FLTK than Qt lately). I suspect that Qt could grow and support more of what people want if it got more attention, but for whatever reason of the cross-platform native toolkits it seems to be less discussed.
-
Especially with QML, Qt feels just like the javascript+bindings world of the web
-
-
-
-
This is an overly simplistic argument that misses the point. Desktop app development has not changed significantly in the past five years, and without Electron we would simply not have many of the Electron-powered cross-platform apps that are popular and used by many today. You can’t talk about “not optimizing for user happiness” when the alternative is these apps just not existing.
I don’t like the Slack app, it’s bloated and slow. I wouldn’t call myself a JavaScript developer, and I think a lot of stuff in that world is too ruled by fashion. But this posturing and whining by people who are “too cool for Electron” is just downright silly.
Make a better alternative. It’s not like making an Electron app is morally worse than making a desktop app. When you say “we need to make desktop app development better” you can’t impose an obligation on anyone but yourself.
-
without Electron we would simply not have many of the Electron-powered cross-platform apps that are popular and used by many today.
I don’t really remember having a problem finding desktop applications before Electron. There seems to be relatively little evidence for this statement.
-
Please do not straw man. If you read what you quoted, you will see I did not say no desktop apps existed before Electron. That’s absurd. You also conveniently ignored the part of my sentence where I say “cross-platform”.
Obviously we can’t turn back the clock and rewrite history, so what evidence would suffice for you? Maybe it would be the developers of cross-platform apps like Slack, Atom, and VS Code writing about how Electron was a boon for them. Or it could be the fact that the primary cross-platform text editors we had before Electron were Vim and Emacs. Be reasonable (and more importantly, civil.)
-
I think Vim and Emacs, traditional tools of UNIX folks, propped up as examples of what Slack or VS Code replaced is also a fallacy you’re using to justify a need for Electron. Maybe better comparisons would be Xchat/HexChat/Pidgin, UltraEdit or SlickEdit for editor, and NetBeans or IntelliJ IDEA for IDE. So, those products sucked compared to Electron apps for reasons due to cross-platform technology used vs other factors? Or do they suck at all?
Nah, if anything, they show these other projects couldve been built without Electron. Whether they should or not depends on developers’ skills, constraints, preferences, etc on top of markets. Maybe Electron brings justifiable advantages there. Electron isnt making more sophisticated apps than cross-platform native that Ive seen, though.
-
I think you and the other poster are not making it very clear what your criterion for evidence is. You’ve set up a non-falsifiable claim that simply depends on too many counterfactuals.
In the timeline we live in, there exist many successful apps written in Electron. I don’t like many of them, as I’ve stated. I certainly would prefer native apps in many cases.
All we need to do is consider the fact that these apps are written in Electron and that their authors have explicitly stated that they chose Electron over desktop app frameworks. If you also believe that these apps are at all useful then this implies that Electron has made it easier for developers to make useful cross-platform apps. I’m really not sure why we are debating about whether a implies b and b implies c means a implies c.
You point out the examples of IntelliJ and XChat. I think these are great applications. But you are arguing against a point no one is making.
“Electron is just fashion, Slack and VS Code aren’t really useful to me so there aren’t any useful Electron apps” is not a productive belief and not a reasonable one. I don’t like Slack and I don’t particularly like VS Code. But denying that they are evidence that Electron is letting developers create cross-platform apps that might not have existed otherwise and that are useful to many people requires a lot of mental gymnastics.
-
“You point out the examples of IntelliJ and XChat. I think these are great applications. But you are arguing against a point no one is making.”
You argued something about Electron vs cross-platform native by giving examples of modern, widely-used apps in Electron but ancient or simplistic ones for native. I thought that set up cross-platform native to fail. So, I brought up the kind of modern, widely-used native apps you should’ve compared to. The comparison then appeared to be meaningless given Electron conveyed no obvious benefits over those cross-platform, native apps. One of the native apps even supported more platforms far as I know.
“All we need to do is consider the fact that these apps are written in Electron and that their authors have explicitly stated that they chose Electron over desktop app frameworks. If you also believe that these apps are at all useful then this implies that Electron has made it easier for developers to make useful cross-platform apps. “
It actually doesn’t unless you similarly believe we should be writing business apps in COBOL on mainframes. Visual Basic 6, or keeping the logic in Excel spreadsheets because those developers or analysts were doing it saying it was easiest, most-effective option. I doubt you’ve been pushing those to replace business applications in (favorite language here). You see, I believe that people using Electron to build these apps means it can be done. I also think something grounded in web tech would be easier to pick up for people from web background with no training in other programming like cross-platform native. This much evidence behind that as a general principle and for Electron specifically. The logic chain ends right here though:
“then this implies that Electron has made it easier for developers to make useful cross-platform apps.”
It does not imply that in general case. What it implies is the group believed it was true. That’s it. All the fads that happen in IT which the industry regretted later on tells me what people believe was good and what objectively was are two different things with sadly little overlap. I’d have to assess things like what their background was, were they biased in favor of or against certain languages, whether they were following people’s writing who told them to use Electron or avoid cross-platform native, whether they personally or via the business were given constraints that excluded better solutions, and so on. For example, conversations I’ve had and watched with people using Electron have showed me most of them didn’t actually know much about the cross-platform native solutions. The information about what would be easy or difficult had not even gotten to them. So, it would’ve been impossible for them to objectively assess whether they were better or worse than Electron. It was simply based on what was familiar, which is an objective strength, to that set of developers. Another set of developers might have not found it familiar, though.
So, Electron is objectively good for people how already know web development looking for a solution with good tooling for cross-platform apps to use right now without learning anything else in programming. That’s a much narrower claim than it being better or easier in general for cross-platform development, though. We need more data. Personally, I’d like to see experiments conducted with people using Electron vs specific cross-platform native tooling to see what’s more productive with what weaknesses. Then, address the weaknesses for each if possible. Since Electron is already popular, I’m also strongly in favor of people with the right skills digging into it to make it more efficient, secure, etc by default. That will definitely benefit lots of users of Electron apps that developers will keep cranking out.
-
Hey, I appreciate you trying to have a civilized discussion here and in your other comments, but at this point I think we are just talking past each other. I still don’t see how you can disagree with the simple logical inference I made in my previous comment, and despite spending some effort I don’t see how it at all ties into your hypothetical about COBOL. It’s not even a hypothetical or a morality or efficacy argument, just transitivity, so I’m at a loss as to how to continue.
At this point I am agreeing with everything you are saying except on those things I’ve already said, and I’m not even sure if you disagree with me on those areas, as you seem to think you do. I’m sorry I couldn’t convince you on those specifics, which I think are very important (and on which other commenters have strongly disagreed with me), but I’ve already spent more time than I’d have preferred to defending a technology I don’t even like.
On the other hand, I honestly didn’t mind reading your comments, they definitely brought up some worthwhile and interesting points. Hope you have a good weekend.
-
Yeah, we probably should tie this one up. I thank you for noticing the effort I put into being civil about it and asking others to do the same in other comments. Like in other threads, I am collecting all the points in Electron’s favor along with the negatives in case I spot anyone wanting to work on improvements to anything we’re discussing. I got to learn some new stuff.
And I wish you a good weakend, too, Sir. :)
-
-
-
-
-
Please do not straw man. If you read what you quoted, you will see I did not say no desktop apps existed before Electron
And if you read what I said, I did not claim that you believed there were no desktop apps before Electron. If you’re going to complain about straw men, please do not engage in them yourself.
My claim was that there was no shortage of native applications, regardless of the existence of electron. This includes cross platform ones like xchat, abiword, most KDE programs, and many, many others. They didn’t always feel entirely native on all platforms, but the one thing that Electron seems to have done in order to make cross platform easy is giving up on fitting in with all the quirks of the native platform anyways – so, that’s a moot point.
Your claim, I suppose, /is/ tautologically true – without electron, there would be no cross platform electron based apps. However, when the clock was rolled back to before electron existed and look at history, there were plenty of people writing enough native apps for many platforms. Electron, historically, was not necessary for that.
It does let web developers develop web applications that launch like native apps, and access the file system outside of the browser, without learning new skills. For quickly getting a program out the door, that’s a benefit.
-
No one is saying there was a “shortage” of desktop applications; I’m not sure how one could even ascribe that belief to someone else without thinking they were completely off their rocker. No one is even claiming that without Electron none of these apps would exist (read my comment carefully). My claim is also not the weird tautology you propose, and again I’m not sure why you would ascribe it to someone else if you didn’t think they were insane or dumb. This is a tactic even worse than straw manning, so I’m really not sure you why you are so eager to double down on this.
Maybe abstracting this will help you understand. Suppose we live in a world where method A doesn’t exist. One day method A does exist, and although it has lots of problems, some people use method A to achieve things B that are useful to other people, and they publicly state that they deliberately chose method A over older methods.
Now. Assuming other people are rational and that they are not lying [1], we can conclude that method A helped people achieve things B in the sense that it would have been more difficult had method A not existed. Otherwise these people are not being rational, for they chose a more difficult method for no reason, or they are lying, and they chose method A for some secret reason.
This much is simple logic. I really am not interested in discussing this if you are going to argue about that, because seriously I already suspect you are being argumentative and posturing for no rational reason.
So, if method A made it easier for these people to achieve things B, then, all else equal, given that people can perform a finite amount of work, again assuming they are rational, we can conclude that unless the difference in effort really was below the threshold where it would cause any group of people to have decided to do something else [2], if method A had not existed, then some of the things B would not exist.
This is again seriously simple logic.
I get it that it’s cool to say that modern web development is bloated. For the tenth time, I agree that Electron apps are bloated. As I’ve stated, I don’t even like Slack, although it’s ridiculous that I have to say that. But don’t try to pass off posturing as actual argument.
[1]: If you don’t want to assume that at least some of the people who made popular Electron apps are acting intelligently in their own best interests, you really need to take a long hard look at yourself. I enjoy making fun of fashion-driven development too, but to take it to such an extreme would be frankly disturbing.
[2]: If you think the delta is really so small, then why did the people who created these Electron apps not do so before Electron existed? Perhaps the world changed significantly in the meantime, and there was no need for these applications before, and some need coincidentally arrived precisely at the same time as Electron. If you had made this argument, I would be a lot more happy to discuss this. But you didn’t, and frankly, this is too coincidental to be a convincing explanation.
-
then why did the people who created these Electron apps not do so before Electron existed?
…wut.
Apps with equivalent functionality did exist. The “Electron-equivalent” apps were a time a dozen, but built on different technologies. People creating these kinds of applications clearly did exist. Electron apps did not exist before electron, for what I hope are obvious reasons.
And, if you’re trying to ask why web developers who were familiar with a web toolkit running inside a browser, and unfamiliar with desktop toolkits didn’t start writing things that looked like desktop applications until they could write them inside a web browser… It’s easier to do something when you don’t have to learn new things.
There is one other thing that Electron did that makes it easier to develop cross platform apps, though. It dropped the idea of adhering fully to native look and feel. Subtle things like, for example, the way that inspector panels on OSX follow your selection, while properties dialogs on Windows do not – getting all that right takes effort.
At this point, I don’t really see a point in continuing, since you seem to consistently be misunderstanding and aor misinterpreting everything that’s been said in this entire thread, in replies to both me and others. I’m not particularly interested in talking to someone who is more interested in accusing me of posturing than in discussing.
Thank you for your time.
-
I am perplexed how you claim to be the misunderstood one when I have literally been clarifying and re-clarifying my original comment only to see you shift the goalposts closer and closer to what I’ve been saying all along. Did you even read my last comment? Your entire comment is literally elaborating on one of my points, and your disagreement is literally what I spent my entire comment discussing.
I’m glad you thanked me for my time, because then at least one of us gained something from this conversation. I honestly don’t know what your motives could be.
-
-
-
-
I find it strange that you somehow read
I don’t really remember having a problem finding desktop applications before Electron
as implying that you’d said
no desktop apps existed before Electron
@orib was simply saying that there was no shortage of desktop apps before Electron. That’s much different.
…That’s absurd… Obviously we can’t turn back the clock and rewrite history… …Be reasonable (and more importantly, civil.)
You should take your own advice. @orib’s comment read as completely anodyne to me.
-
-
You seem to be confusing me with somebody else.
-
Please, please stop continuing to derail this conversation. I am now replying to your contentless post which itself was a continuation of your other contentless post which was a reply to my reply to orib’s post, which at least had some claims that could be true and could be argued against.
I’m not sure what your intentions are here, but it’s very clear to me now that you’re not arguing from a position of good faith. I regret having engaged with you and having thus lowered the level of discourse.
-
Please, please stop continuing to derail this conversation… I regret having engaged with you and having thus lowered the level of discourse.
Yeah, I wouldn’t want to derail this very important conversation in which @jyc saves the Electron ecosystem with his next-level discourse.
My intention was to call you out for being rude and uncivil and the words you’ve written since then only bolster my case.
-
What is even your motive? Your latest comment really shows you think this whole thing is some sort of sophistic parlor game. I have spent too much time trying to point out that there may even exist some contribution from a technology I don’t even like. I honestly hope you find something better to do with your time than start bad faith arguments with internet strangers for fun.
-
-
-
-
-
-
-
-
I’m not sure sure that it’s necessarily true that the existence of these apps is necessarily better than the alternative. For a technical audience, sure. I can choose to, grudgingly, use some bloated application that I know is going to affect my performance, and I’m technical enough to know the tradeoffs and how to mitigate the costs (close all electron apps when I’m running on battery, or doing something that will benefit from more available memory). The problem is for a non-technical audience who doesn’t understand these costs, or how to manage their resources, the net result is a degraded computing experience- and it affects the entire computing ecosystem. Resource hog applications are essentially replaying the tragedy of the commons on every single device they are running on, and even as the year-over-year gains in performance are slowing the underlying problem seems to be getting worse.
And when I say “we” should do better, I’m acknowledging that the onus to fix this mess is going to be in large part on those of us who have started to realize there’s a problem. I’m not sure we’ll succeed as javascript continues to eat the world, but I’ll take at least partial ownership over the lack of any viable contenders from the native application world.
-
I’m not sure sure that it’s necessarily true that the existence of these apps is necessarily better than the alternative.
I think this and your references to a “tragedy of the commons” and degrading computing experiences are overblowing the situation a bit. You may not like Slack or VS Code or any Electron app at all, but clearly many non-technical and technical people do like these apps and find them very useful.
I agree 100% that developers should be more cautious about using user’s resources. But statements like the above seem to me to be much more like posturing than productive criticism.
Electron apps are making people’s lives strictly worse by using up their RAM—seriously? I don’t like Electron hogging my RAM as much as you, but to argue that it has actually made people’s lives worse than if it didn’t exist is overdramatic. (If you have separate concerns about always-on chat apps, I probably share many of them, but that’s a separate discussion).
-
but clearly many non-technical and technical people do like these apps and find them very useful.
If you heard the number of CS folks I’ve heard complain about Slack clients destroying their productivity on their computers by lagging and breaking things, you’d probably view this differently.
-
-
Dude, seriously, the posturing is not cool or funny at this point. I myself complain about Slack being bloated, and IIRC I even complained about this in my other post. Every group I’ve been that has used Slack I’ve also heard complaints about it from both technical and non-technical people.
I’ll leave it as an exercise for you to consider how this is not at all a contradiction with what you quoted. My God, the only thing I am more annoyed by at this point than Electron hipsterism is the anti-Electron hipsterism.
-
Not posturing–this is a legitimate problem.
Dismissing the very real pain points of people using software that they’re forced into using because Slack is killing alternatives is really obnoxious.
People aren’t complaining just to be hipsters.
-
Dude, at this point I suspect you and others in this thread are trying to imagine me as some personification of Electron/Slack so that you can vent all your unrelated complaints about them to me. For the last time, I don’t even like Electron and Slack that much. What is obnoxious is the fact that you are just ignoring the content of my comments and using them as a springboard for your complaints about Slack which I literally share.
You seriously call this account @friendlysock?
Your latest comment doesn’t add anything at all. Many users, perhaps even a majority of users, find Slack and other Electron software useful. I don’t and you don’t. I don’t like Slack’s business practices and you don’t either. Seriously, read the damn text of my comment and think about how you are barking up the entirely wrong tree.
-
-
-
-
-
-
“and without Electron we would simply not have many of the Electron-powered cross-platform apps that are popular and used by many today. “
What that’s actually saying is that people who envision and build cross-platform apps for their own satisfaction, fame, or fortune would stop doing that if Electron didnt exist. I think the evidence we have is they’d build one or more of a non-portable app (maybe your claim), cross-platform app natively, or a web app. That’s what most were doing before Electron when they had the motivations above. Usually web, too, instead of non-portable.
We didnt need Electron for these apps. Quite a few would even be portable either immediately or later with more use/funds. The developers just wanted to use it for whatever reasons which might vary considerably among them. Clearly, it’s something many from a web background find approachable, though. That’s plus development time savings is my theory.
-
I agree that many people might have ended up building desktop apps instead that could have been made even better over time. I also agree with your theory about why writing Electron apps is popular. Finally, I agree that Electron is not “needed”.
I’m going to preemptively request that we keep “hur dur, JavaScript developers, rational?” comments out of this—let’s be adults: assuming the developers of these apps are rational, clearly they thought Electron was the best choice for them. Anyone “sufficiently motivated” would be willing to write apps in assembler; that doesn’t mean we should be lamenting the existence of bloated compilers.
Is saying developers should think about writing apps to use less resources productive? Yes. Is saying Electron tends to create bloated apps productive? Definitely. Is saying Electron makes the world a strictly worse place productive or even rational? Not at all.
-
“I’m going to preemptively request that we keep “hur dur, JavaScript developers, rational?” comments out of this—let’s be adults”
Maybe that was meant for a different commenter. I haven’t done any JS bashing in this thread that I’m aware of. I even said Electron is good for them due to familiarity.
“ Is saying Electron makes the world a strictly worse place productive or even rational? Not at all.”
Maybe that claim was also meant for a different commenter. I’d not argue it at all since those using Electron built some good software with it.
I’ve strictly countered false positives in favor of Electron in this thread rather than saying it’s all bad. Others are countering false negatives about it. Filtering the wheat from the chaff gets us down to the real arguments for or against it. I identified one, familiarity, in another comment. Two others brought up some tooling benefits such as easier support for a web UI and performance profiling. These are things one can make an objective comparison with.
-
-
-
-
forget that a user want’s to do things other than constantly interact with that one single application for their entire computing existence.
Quoted for truth.
Always assume that your software is sitting between your user and what they actually want to do. Write interactions accordingly.
We don’t pay for software because we like doing the things it does, we pay so we don’t have to keep doing those things.
-
perhaps because of the licensing model
I also think so. It’s fine for open source applications, but the licensing situation for proprietary applications is tricky. Everyone who says you can use Qt under LGPL and just have to dynamically link to Qt, also says “but I’m not a lawyer so please consult one”. As a solo developer working on building something that may or may not sell at some point, it’s not an ideal situation to be in.
-
I think the big caveat to this is that for a great many of the applications I see that have electron-based desktop apps, they are frontends for SAAS applications. They could make money off a GPL application just as easily as a proprietary one, especially since a lot of these services publish most of the APIs anyway.
Granted, I’d love to see a world where software moved away from unnecessary rent-seeking and back to actually selling deliverable applications, but as long as we’re in a SAAS-first world the decision to release a decent GPL-ed frontend doesn’t seem like it should be that hard.
-
I have been responsible for third party IP at a company that did exactly that with Qt; it’s fine.
-
-
The situation is more nuanced than that. Because Electron provides developers with a better workflow and a lower barrier to entry that results in applications and features that simply wouldn’t exist otherwise. The apps built with Electron might not be as nice as native ones, but they often solve real problems as indicated by the vast amount of people using them. This is especially important if you’re running Linux where apps like Slack likely wouldn’t even exist in the first place, and then you’d be stuck having to try running them via Wine hoping for the best.
While Qt is probably one of the better alternatives, it breaks down if you need to have a web UI. I’d also argue that the workflow you get with Electron is far superior.
I really don’t see any viable alternatives to Electron at the moment, and it’s like here to stay for the foreseeable future. It would be far more productive to focus on how Electron could be improved in terms of performance and resource usage than to keep complaining about it.
-
I never claimed that it doesn’t make life easier for some developers, or even that every electron app would have been written with some other cross-platform toolkit. Clearly for anyone who uses Javascript as their primary (or, in many cases, only) language, and works with web technology day in and day out, something like electron is going to be the nearest to hand and the fastest thing for them to get started with.
The problem I see is that what’s near to hand for developers, and good for the individual applications, ends up polluting the ecosystem by proliferating grossly, irresponsibly inefficient applications. The problem of inefficiency and the subsequent negative affect it has on the entire computing ecosystem is compounded by the fact that most users aren’t savvy enough to understand the implications of the developers technology choices, or even capable of looking at the impact that a given application is having on their system. Additionally, software as an industry is woefully prone to adopting local maxima solutions- even if something better did come along, we’re starting to hit an inflection point of critical mass where electron will continue to gain popularity. Competitors might stand a chance if developers seemed to value efficiency, and respect the resources of their users devices, but if they did we wouldn’t be in this situation in the first place.
-
Saying that developers use Electron simply because don’t value efficiency is absurd. Developers only have so much time in a day. Maintaining the kinds of applications built with Electron using alternatives is simply beyond the resources available to most development teams.
Again, as I already pointed out, the way to address the problem is to look for ways to improve Electron as opposed to complaining that it exists in the first place. If Electron runtime improves, all the applications built on top of it automatically get better. It’s really easy to complain that something is bloated and inefficient, it’s a lot harder to do something productive about it.
-
-
-
but I shouldn’t have to be killing slack and zoom every time I unplug my laptop
Yes, you shouldn’t. But that is not Electron’s fault.
I’ve worked on pgManage, and even though ii is based on Electron for the front-end, we managed to get it work just fine and use very little CPU/Memory*. Granted, that’s not a chat application, but I also run Riot.im all day everyday and it show 0% CPU and 114M of memory (about twice as much as pgManage).
Slack is the worst offender that I know of, but it’s because the people who developed it were obviously used to “memory safe” programming. We had memory issues in the beginning with the GC not knowing what to do when we were doing perfectly reason able things. But we put the effort in and made it better.
We have a strong background in fast C programs, and we applied that knowledge to the JS portion of pgManage and cut down the idle memory usage to 58M. For this reason, I’m convinced that C must never die.
* https://github.com/pgManage/pgManage/blob/master/Facts_About_Electron_Performance.md (Note: the version numbers referred to in this article are for Postage, which was later re-branded pgManage)
*Edit for spelling*
-
“But that is not Electron’s fault.”
It happens by default with a lot of Electron apps. It doesnt so much with native ones. That might mean it’s a side effect of Electron’s design. Of course, Id like to see more data on different use-cases in case it happens dor some things but not others. In your case, did you have to really work hard at keeping the memory down?
Edit: The Github link has some good info. Thanks.
-
It happens by default with a lot of Electron apps.
I see where your coming from, and you’re right, but if more JS devs had C experience (or any other non-memory-managed language), we would all be better for it. The GC spoils, and it doesn’t always work.
It doesnt so much with native ones.
Yes, but I think that greatly depends on the language, and how good the GC is.
That might mean it’s a side effect of Electron’s design.
Maybe, but if pgManage can do it (a small project with 5 people working on it), than I see absolutely no reason why Slack would have any difficulty doing it.
In your case, did you have to really work hard at keeping the memory down?
Yes and no. Yes it took time (a few days at most), but no because Electron, and Chrome, have great profiling tools and we were able to find most issues fairly quickly (think Valgrind). IIRC the biggest problem we had at the time was that event listeners weren’t being removed before an element was destroyed (or something like that).
-
One thing I’ll note, look at the ipc ratio of electron apps versus other native apps. You’ll notice a lot of tlb misses and other such problems meaning that the electron apps are mostly sitting there forcing the cpu to behave in ways it really isn’t good at optimizing.
In the end, the electron apps just end up using a lot of power spinning the cpu around compared to the rest. This is technically also true of web browsers.
You may use perf on linux or tiptop to read the cpu counters (for general ipc eyeballing i’d use tiptop): http://tiptop.gforge.inria.fr
-
-
-
-
-
tschellenbach
5 years ago
|
link
| on:
Too Big to Let Others Fail Us: How Mark Zuckerberg Blamed Facebook's Problems On Openness
Well yes a lot of their issues are caused by having APIs that are too open. To be fair, back in those days, the tech ecosystem was definitely pushing for this openness. It was considered a good thing. Now, not so much..
-
In our buzzwords-driven field?
Probably people considered API access “a good thing” just because “Facebook/Google is doing this too!”
But the problem was not the technology back then, just like AI is not the solution right now.
It’s the business model.
I remember a younger Zuckerberg explaining the world how privacy had no value for modern people.
He meant it!
-
back in those days, the tech ecosystem was definitely pushing for this openness.
I would hardly call 2015 “those days”.
-
Back in my day…
-
-
-
I’ve talked to some people in and close to this industry and it feels like we’re a good 15 years away from autonomous vehicles. The other major issue we’re not addressing is that these cars cannot be closed source like they are now. At a minimum, the industry needs to share with each other and be using the same software or same algorithms. We can’t enter a world where Audi claims their autonomous software is better than Nissan’s in adverts.
People need to realize they won’t be able to own these cars or modify them in any way if they ever do come to market. The safety risks would be too great. If the cars are all on the same network, one security failure could mean a hacker could kill thousands of people at once.
I really think the current spending on this is a huge waste of money, especially in America when tax money given to companies to subsidize research could be used to get back the trains system we lost and move cities back inward like they were in the earlier 1900s. I’ve written about this before:
http://penguindreams.org/blog/self-driving-cars-will-not-solve-the-transportation-problem/
-
-
Also human-driven cars.
-
-
-
-
-
Serious question (given that you’ve worked on self-driving cars): is computer vision advanced enough today to be able to reliably and consistently detect the difference between blinkers and hazards for all car models on the roads today?
-
As often is the case, some teams will definitely be able to do it, and some teams won’t.
Cities and States should use it as part of a benchmark to determine which self-driving cars are allowed on the road, in exactly the same way that humans must pass a test before they’re allowed a drivers license.
The test for self-driving cars should be harder than the test for humans, not easier.
-
-
-
-
-
-
The other major issue we’re not addressing is that these cars cannot be closed source like they are now.
I strongly agree with this. I believe autonomous vehicles are the most important advancement in automotive safety since the seatbelt. Can you imagine if Volvo had kept a patent on the seatbelt?
The autonomous vehicle business shouldn’t be about whose car drives the best, it should be about who makes the better vehicles. Can you imagine the ads otherwise? “Our vehicles kill 10% fewer people than our competitors!” Ew.
-
I don’t buy your initial claims.
When you said “we’re 15 years away from autonomous vehicles”, what do you mean exactly? That it’ll be at least 15 years before the general public can ride in them? Waymo claims this will happen in Pheonix this year: https://amp.azcentral.com/amp/1078466001 That the majority of vehicles on US roads will be autonomous? Yeah, that’ll definitely take over 15 years!
We can have a common/standard set of rigorous tests that all companies need to pass but we don’t need them to literally all use the same exact code. We don’t do that for aeroplanes or elevators either. And the vanguard of autonomous vehicles are large corporations that aren’t being funded by tax dollars.
That said, I agree that it would be better to have more streetcars and other light rail in urban areas.
-
It will be at least 15 years before fully autonomous vehicles are available for sale or unrestricted lease to the general public. (In fact, my estimate is more like twice that.) Phoenix is about the most optimal situation imaginable for an autonomous vehicle that’s not literally a closed test track. Those vehicles will be nowhere near equipped to deal with road conditions in, for example, a northeastern US winter, which is a prerequisite to public adoption, as opposed to tests which happen to involve the public.
Also, it’s a safe bet this crash will push back everyone’s timelines even further.
-
-
-
When you learn C++ you learn that a const& can bind to temporaries. It’s common knowledge. Nothing I have ever read in the C++ literature has caused me to associate reference type with lifetime. Obviously Rust’s strict ownership/lifetime rules are better but if you’re simply going to wish guarantees into existence you will have problems programming in any language.