-
I do this for all my sites. It really should be the default, or at least more obvious.
-
Writing a
robotfindschickenclone in Scheme for kicks. It’s fun but feels sorta sinful to write in a nearly purely imperative way in a language like this. I guess there’s no way around withncurses.-
Scheme FRP library?
-
-
-
This blogpost is a good example of fragmented, hobbyist security maximalism (sprinkled with some personal grudges based on the tone).
Expecting Signal to protect anyone specifically targeted by a nation-state is a huge misunderstanding of the threat models involved.
Talking about threat models, it’s important to start from them and that explains most of the misconceptions in the post.
- Usable security for the most people possible. The vast majority people on the planet use iOS and Android phones, so while it is theoretically true that Google or Apple could be forced to subvert their OSs, it’s outside the threat model and something like that would be highly visible, a nuclear option so to speak.
- Alternative distribution mechanisms are not used by 99%+ of the existing phone userbases, providing an APK is indeed correctly viewed as harm reduction.
- Centralization is a feature. Moxie created a protocol and a service used by billions and millions of people respectively that provides real, measureable security for a lot of people. The fact is that doing all this in a decentralized way is something we don’t yet know how to do or doing invites tradeoffs that we shouldn’t make. Federation atm either leads to insecurity or leads to the ossification of the ecosystem, which in turn leads to a useless system for real users. We’ve had IRC from the 1990s, ever wonder why Slack ever became a thing? Ossification of a decentralized protocol. Ever wonder why openpgp isn’t more widespread? Noone cares about security in a system where usability is low and design is fragile. Ever tried to do key rotation in gpg? Even cryptographers gave up on that. Signal has that built into the protocol.
Were tradeoffs made? Yes. Have they been carefully considered? Yes. Signal isn’t perfect, but it’s usable, high-level security for a lot of people. I don’t say I fully trust Signal, but I trust everything else less. Turns out things are complicated when it’s about real systems and not fantasy escapism and wishes.
-
Expecting Signal to protect anyone specifically targeted by a nation-state is a huge misunderstanding of the threat models involved.
In this article, resistance to governments constantly comes up as a theme of his work. He also pushed for his tech to be used to help resist police states like with the Arab Spring example. Although he mainly increased the baseline, the tool has been pushed for resisting governments and articles like that could increase perception that it was secure against governments.
This nation-state angle didn’t come out of thin air from paranoid, security people: it’s the kind of thing Moxie talks about. In one talk, he even started with a picture of two, activist friends jailed in Iran in part to show the evils that motivate him. Stuff like that only made the stuff Drew complains about on centralization, control, and dependence on cooperating with surveillance organization stand out even more due to the inconsistency. I’d have thought he’d make signed packages for things like F-Droid sooner if he’s so worried about that stuff.
-
A problem with the “nation-state” rhetoric that might be useful to dispel is the idea that it is somehow a God-tier where suddenly all other rules becomes defunct. The five-eyes are indeed “nation state” and has capabilities that are profound; like the DJB talk speculating about how many RSA-1024 keys that they’d likely be able to factor in a year given such and such developments and what you can do with that capability. That’s scary stuff. On the other hand, this is not the “nation state” that is Iceland or Syria. Just looking at the leaks from the “Hacking Team” thing, there are a lot of “nation states” forced to rely on some really low quality stuff.
I think Greg Conti in his “On Cyber” setup depicts it rather well (sorry, don’t have a copy of the section in question) and that a more reasonable threat model of capable actors you do need to care about is that of Organized Crime Syndicates - which seems more approachable. Nation State is something you are afraid of if you are political actor or in conflict with your government, where the “we can also waterboard you to compliance” factors into your threat model, Organized Crime hits much more broadly. That’s Ivan with his botnet from internet facing XBMC^H Kodi installations.
I’d say the “Hobbyist, Fragmented Maximalist” line is pretty spot on - with a dash of “Confused”. The ‘threats’ of Google Play Store (test it, write some malware and see how long it survives - they are doing things there …) - the odds of any other app store; Fdroid, the ones from Samsung, HTC, Sony et al. - being completely owned by much less capable actors is way, way higher. Signal (perhaps a Signal-To-Threat ratio?) perform an good enough job in making reasonable threat actors much less potent. Perhaps not worthy of “trust”, but worthy of day to day business.
-
-
Expecting Signal to protect anyone specifically targeted by a nation-state is a huge misunderstanding of the threat models involved.
And yet, Signal is advertising with the face of Snowden and Laura Poitras, and quotes from them recommending it.
What kind of impression of the threat models involved do you think does this create?
-
-
Whichever ones are normally on the media for information security saying the least amount of bullshit. We can start with Schneier given he already does a lot of interviews and writes books laypeople buy.
-
-
He encourages use of stuff like that to increase baseline but not for stopping nation states. He adds also constantly blogged about the attacks and legal methods they used to bypass technical measures. So, his reporting was mostly accurate.
We counterpoint him here or there but his incentives and reo are tied to delivering accurate info. Moxie’s incentives would, if he’s selfish, lead to locked-in to questionable platforms.
-
-
-
-
-
We’ve had IRC from the 1990s, ever wonder why Slack ever became a thing? Ossification of a decentralized protocol.
I’m sorry, but this is plain incorrect. There are many expansions on IRC that have happened, including the most recent effort, IRCv3: a collectoin of extensions to IRC to add notifications, etc. Not to mention the killer point: “All of the IRCv3 extensions are backwards-compatible with older IRC clients, and older IRC servers.”
If you actually look at the protocols? Slack is a clear case of Not Invented Here syndrome. Slack’s interface is not only slower, but does some downright crazy things (Such as transliterating a subset of emojis to plain-text – which results in batshit crazy edge-cases).
If you have a free month, try writing a slack client. Enlightenment will follow :P
-
I’m sorry, but this is plain incorrect. There are many expansions on IRC that have happened, including the most recent effort, IRCv3: a collectoin of extensions to IRC to add notifications, etc. Not to mention the killer point: “All of the IRCv3 extensions are backwards-compatible with older IRC clients, and older IRC servers.”
Per IRCv3 people I’ve talked to, IRCv3 blew up massively on the runway, and will never take off due to infighting.
-
-
There are swathes of people still using Windows XP.
The primary complaint of people who use Electron-based programs is that they take up half a gigabyte of RAM to idle, and yet they are in common usage.
The fact that people are using something tells you nothing about how Good that thing is.
At the end of the day, if you slap a pretty interface on something, of course it’s going to sell. Then you add in that sweet, sweet Enterprise Support, and the Hip and Cool factors of using Something New, and most people will be fooled into using it.
At the end of the day, Slack works just well enough Not To Suck, is Hip and Cool, and has persistent history (Something that the IRCv3 group are working on: https://ircv3.net/specs/extensions/batch/chathistory-3.3.html)
-
At the end of the day, Slack works just well enough Not To Suck, is Hip and Cool, and has persistent history (Something that the IRCv3 group are working on […])
The time for the IRC group to be working on a solution to persistent history was a decade ago. It strikes me as willful ignorance to disregard the success of Slack et al over open alternatives as mere fashion in the face of many meaningful functionality differences. For business use-cases, Slack is a better product than IRC full-stop. That’s not to say it’s perfect or that I think it’s better than IRC on all axes.
To the extent that Slack did succeed because it was hip and cool, why is that a negative? Why can’t IRC be hip and cool? But imagine being a UX designer and wanting to help make some native open-source IRC client fun and easy to use for a novice. “Sisyphean” is the word that comes to mind.
If we want open solutions to succeed we have to start thinking of them as products for non-savvy end users and start being honest about the cases where closed products have superior usability.
-
IRC isn’t hip and cool because people can’t make money off of it. Technologies don’t get investment because they are good, they get good because of investment. The reason that Slack is hip/cool and popular and not IRC is because the investment class decided that.
It also shows that our industry is just a pop culture and can give a shit about good tech .
-
There were companies making money off chat and IRC. They just didn’t create something like Slack. We can’t just blame the investors when they were backing companies making chat solutions whose management stayed on what didn’t work in long-term or for huge audience.
-
-
My point was there were companies selling chat software, including IRC clients. None pulled off what Slack did. Even those doing IRC with money or making money off it didn’t accomplish what Slack did for some reason. It would help to understand why that happened. Then, the IRC-based alternative can try to address that from features to business model. I don’t see anything like that when most people that like FOSS talk Slack alternatives. Then, they’re not Slack alternatives if lacking what Slack customers demand.
-
Thanks for clarifying. My point can be restated as… There is no business model for federated and decentralized software (until recently , see cryptocurrencies). Note most open and decentralized tech of the past was government funded and therefore didn’t face business pressures. This freed designets to optimise other concerns instead of business onrs like slack does.
-
-
-
-
-
-
Right, as I said I think it’s important for proponents of open tech to look at successful products like Slack and try to understand why they succeeded. If you really think there is no meaningful difference then I think you’re totally disconnected from the needs/context of the average organization or computer user.
-
That’s all well and good, I just don’t see why we can’t build those systems on top of existing open protocols like IRC. I mean: of course I understand, it’s about the money. My opinion is that it doesn’t make much sense to insist that opaque, closed ecosystems are the way to go. We can have the “hip-and-cool” factor, and all the amenities provided by services like Slack, without abandoning the important precedent we’ve set for ourselves with protocols like IRC and XMPP. I’m just disappointed that everyone’s seeing this as an “either-or” situation.
-
-
-
-
-
Open, standard chat tech has had persistent history and much more for decades in the form of XMPP. Comparing to the older IRC on features isn’t really fair.
-
-
I don’t see how Good and “good enough to solve a problem” are related here. The first is a metric of quality, the second is the literal bare minimum of that metric.
-
-
-
-
-
Alternative distribution mechanisms are not used by 99%+ of the existing phone userbases, providing an APK is indeed correctly viewed as harm reduction.
I’d dispute that. People who become interested in Signal seem much more prone to be using F-Droid than, say, WhatsApp users. Signal tries to be an app accessible to the common person, but few people really use it or see the need… and often they are free software enthusiasts or people who are fed up with Google and surveillance.
-
-
Ossification of a decentralized protocol.
IRC isn’t decentralised… it’s not even federated
-
-
I can’t decide if Let’s Encrypt is a godsend or a threat.
On one hand, it let you support HTTPS for free.
On the other, they collect an enourmous power worldwide.-
Agreed, they are quickly becoming the only game in town worth playing with when it comes to TLS certs. Luckily they are a non-profit, so they have more transparency than say Google, who took over our email.
It’s awesome that we have easy, free TLS certs, but there shouldn’t be a single provider for such things.
-
-
OpenCA tried for a long time, and I think now has pretty much given up: https://www.openca.org/ and just exist in their own little bubble now.
Basically nobody wants to certify you unless you are willing to pay out the nose and are considered friendly to the way of doing things. LE bought their way in I’m sure, to get their cert cross-signed, which is how they managed so “quickly” and it still took YEARS.
-
-
I’ve created lots of CAs, trusted by at most 250 people. :)
Of course it’s not easy to make a new generally-trusted CA — nor would I want it to be. It’s a big complicated expensive thing to do properly. But if you’re willing to do the work, and can arrange the funding, is anything stopping you? I don’t know that browser vendors are against the idea of multiple free CAs.
-
Obviously I was not talking about the technical stuffs.
One of my previous boss explored the matter. He had the technical staff already but he wanted to become an official authority. It was more or less 2005.
After a few time (and a lot of money spent in legal consulting) he gave up.
He said: “it’s easier to open a bank”.
In a sense, it’s reasonable, as the European laws want to protect citizens from unsafe organisations.
But, it’s definitely not a technical problem.
-
-
-
-
Luckily they are a non-profit
Linux Foundation is a 501(c)(6) organization, a business league that is not organized for profit and no part of the net earnings goes to the benefit of any private shareholder or individual.
The fact all shareholders benefit from its work without a direct economical gain, doesn’t means it has the public good at heart. Even less the public good of the whole world.It sound a lot like another attempt to centralize the Internet, always around the same center.
It’s awesome that we have easy, free TLS certs, but there shouldn’t be a single provider for such things.
And such certificates protect people from a lot of relatively cheap attacks. That’s why I’m in doubt.
Probably, issuing TLS certificates should be a public service free for each citizen of a state.
-
Oh Jeez. Thanks, I didn’t realize it was not a 501c3, When LE was first coming around they talked about being a non-profit and I just assumed. That’s what happens when I assume.
Proof, so we aren’t just taking @Shamar’s word for it:
Linux Foundation Bylaws: https://www.linuxfoundation.org/bylaws/
Section 2.1 states the 501(c)(6) designation with the IRS.
My point stands, that we do get more transparency this way than we would if they were a private for-profit company, but I agree it’s definitely not ideal.
So you think local cities, counties, states and countries should get in the TLS cert business? That would be interesting.
-
-
The Linux Foundation will provide general and administrative support services, as well as services related to fundraising, financial management, contract and vendor management, and human resources.
This is from the page linked by @philpennock.
I wonder what is left to do for the Let’s Encrypt staff! :-)
I’m amused by how easily people forget that organisations are composed by people.
What if Linux Foundation decides to drop its support?
No funds. No finance. No contracts. No human resources.
Oh and no hosting, too.But hey! I’m mistaken! ;-)
-
Unless you have inside information on the contract, saying LE depends on the Linux Foundation is pure speculation.
I can speculate too. Should the Linux Foundation withdraw support there are plenty of companies and organisations that have a vested interest in keeping LetsEncrypt afloat. They’ll be fine.
-
Agreed.
Feel free to think that it’s a philanthropic endeavour!
I will continue to think it’s a political one.The point (and as I said I cannot answer yet) is if the global risk of a single US organisation being able to break most of HTTPS traffic world wide is worth the benefit of free certificates.
-
Any trusted CA can MITM, though, not just the one that issued the certificate. So the problem is (and always has been) much, much worse than that.
-
-
-
-
-
-
-
What’s Linux Foundation got to do with it? Let’s Encrypt is run by ISRG, Internet Security Research Group, an organization from the IAB/IETF family if memory serves.
They’re a 501(c)(3).
-
LF provide hosting and support services, yes. Much as I pay AWS to run some things for me, which doesn’t lead to Amazon being in charge. https://letsencrypt.org/2015/04/09/isrg-lf-collaboration.html explains the connection.
-
-
-
-
-
-
-
The comments in the post discuss a 5XX vs a 4XX error and that client-side errors should be fixed by the client. Now I am wondering if the GDPR applies to European citizens or people that are currently in Europe (maybe a day trip or what ever). I usually thought that these GDPR filters are using geoIp. But what if a European citizen is in the US and the other way around? I only checked Wikipedia for this and they say the GDPR applies to EU-citizens. So how to figure out if a web client is a EU-citizen? What am I doing wrong?
-
The companies are just trying to protect themselves as best they can. Realistically, a European citizen suing a US-only company in a European court over European law is being frivolous and the company will likely not be affected in any way, so the butt-covering of geoip blocking is more a political statement to potential sue-ers than it is actual legal protection.
-
What is the actual message to European users of such political statement?
We don’t want your money? We don’t want your data? You do not deserve our technology? We are the Spiders of the Web and you are just a fly?
Btw, as an European I would really appreciate a clear statement on a website saying “we are sorry but we cannot protect your data and respect your rights, please search for one of our competitor that can do it better”.
I’m not ironic.
GDPR defines several important rights for the data subject that imply certain investments in cybersecurity and a basic quality of service. Being able to say “I cannot do this right, please ask to someone else” is a sign of professionalism.
-
-
You figure it out by asking them. There are many sites that don’t serve US citizens for various reasons. When you enter them, they ask you to declare you are not a US citizen. It’s as simple as that. If they lie, it’s on them.
Honestly, this GDPR thing has gotten many Americans acting indignated and generally quite irrational over something that hardly changes anything and is not without a slew of precedent. It’s just the first time US companies are visibly seriously affected by law elsewhere. Now you know how it feels. Get over the feeling and deal with it.
-
Well, in principle, I would guess that European courts might be apprehensive about dictating law globally, which would essentially be the case if it was found that GDPR applies to European citizens wherever they may be, and even if a website operator had taken all reasonable precautions to block European citizens from using their cite.
-
GDPR apply to data of European citizens worldwide and to data of non European citizens collected while they are in the Union.
However, if your registration form have a mandatory checkbox “I’m NOT a European citizen and I’m not going to use your services while in the European Union” AND the such checkbox is uncheked by default AND you block all European IPs, I think no European court will ever annoy you.
-
-
-
This is really a non-issue as far as I’m concerned.
Browsers (either standalone or with plugins) let users turn off images, turn off Javascript, override or ignore stylesheets, block web fonts, block video/flash, and block advertisements and tracking. Users can opt-out of almost any part of the web if it bothers them.
On top of that, nobody’s twisting anybody’s arm to visit “heavy” sites like CNN. If CNN loads too much crap, visit a lighter site. They probably won’t be as biased as CNN, either.
Nobody pays attention to these rants because at the end of the day they’re just some random people stating their arbitrary opinions. Rewind 10 or 15 or 20 years and Flash was killing the web, or Javascript, or CSS, or the img tag, or table based layouts, or whatever.
-
Rewind 10 or 15 or 20 years and Flash was killing the web, or Javascript, or CSS, or the img tag, or table based layouts, or whatever
Flash and table based layouts really were and, to the extent that you still see them, are either hostile or opaque to people who require something like a screen reader to use a website. Abuse of javascript or images excludes people with low end hardware. Sure you can disable these things but it’s all too common that there is no functional fallback (apparently I can’t even vote or reply here without javascript being on).
Are these things “killing the web” in the sense that the web is going to stop existing as a result? Of course not, but the fact that they don’t render the web totally unusable is not a valid defense of abuses of these practices.
-
I wouldn’t call any of those things “abuses”, though.
Maybe it all boils down to where the line is drawn between supported hardware and hardware too old to use on the modern web, and everybody will have different opinions. Should I be able to still browser the web on my old 100 Mhz Petnium with 8 Mb of RAM? I could in 1996…
-
Should I be able to still browser the web on my old 100 Mhz Petnium with 8 Mb of RAM?
To view similar information? Absolutely. If what I learn after viewing a web page hasn’t changed, then neither should the requirements to view it. If a 3D visualization helps me learn fluid dynamics, ok, bring it on, but if it’s page of Cicero quotes, let’s stick with the text, shall we?
-
I wouldn’t call any of those things “abuses”, though.
I think table based layouts are really pretty uncontroversially an abuse. The spec explicitly forbids it.
The rest are tradeoffs, they’re not wrong 100% of the time. If you wanted to make youtube in 2005 presumably you had to use flash and people didn’t criticize that, it was the corporate website that required flash for no apparent reason that drew fire. The question that needs to be asked is if the cost is worth the benefit. The reason people like to call out news sites is they haven’t really seen meaningfully new features in two decades (they’re still primarily textual content, presented with pretty similar style, maybe with images and hyperlinks. All things that 90s hardware could handle just fine) but somehow the basic experience requires 10? 20? 100 times the resources? What did we buy with all that bandwidth and CPU time? Nothing except user-hostile advertising as far as I can tell.
-
If you wanted to make youtube in 2005 presumably you had to use flash and people didn’t criticize that
At the time (ok, 2007, same era) I had a browser extension that let people view YouTube without flash by swapping the flash embed for a direct video embed. Was faster and cleaner than the flash-based UI.
-
Maybe you would like this one https://github.com/thisdotvoid/youtube-classic-extension
-
-
I’d say text-as-images and text-as-Flash from the pre-webfont era are abuses too.
-
-
-
-
On top of that, nobody’s twisting anybody’s arm to visit “heavy” sites like CNN. If CNN loads too much crap, visit a lighter site.
Or just use http://lite.cnn.io
-
nobody’s twisting anybody’s arm to visit “heavy” sites like CNN
Exactly. It’s not a “web developers are making the web bloated” problem, it’s a “news organizations are desperate to make money and are convinced that personalized advertising and tons of statistics (Big Data!!) will help them” problem.
Lobsters is light, HN, MetaFilter, Reddit, GitHub, GitLab, personal sites/blogs, various wikis, forums, issue trackers, control panels… Most of the stuff I use is really not bloated.
If you’re reading general world news all day… stop :)
-
-
This is awesome! Signed up. Are you planning on open sourcing it? I’m sure I would self host something like this.
-
Thanks! I’d love to open-source it. However, I can’t justify the time commitment it would take yet. I’ve open-sourced many smaller projects, and I always feel compelled to answer every email I get. I wish I could post it and then just ignore it, but I really can’t.
I did make a deal with myself a long time ago. If I can get enough supporters on Patreon, I will open-source it. The code is already pretty cleaned-up and ready to go. It’s pure PHP, no dependencies. No frameworks or anything.
-
Post code with no email address to contact you? ;)
-
-
Sweet project, man! I’ve already set it up to email me whenever my name is mentioned on reddit. I’m just a poor student so I can’t justify a patreon (or I could, if it were just 1 project, but there are so many projects I’d love to support) so I’ll have to content myself with just saying thanks, it’s a great idea and a great post explaining it.
-
-
-
-
A realization I recently had:
Why don’t we abstract away all display affordances from a piece of code’s position in a file? That is, the editor reads the file, parses its AST, and displays it according to the programmer’s preference (e.g., elastic tabstops, elm-like comma-leading lists, newline/no-newline before opening braces, etc). And prior to save, the editor simply runs it through an uncustomized
prettierfirst.There are a million and one ways to view XML data without actually reading/writing pure XML. Why not do that with code as well?
-
-
And once you take it a step further, it’s clear that it shouldn’t be in a text file in the first place. Code just isn’t text. If you store it as a tree or a graph in some sort of database, it becomes possible to interact with it in much more powerful ways (including displaying it any way you like). We’ve been hobbled by equating display representation with storage format.
-
This talk touches on this issue, along with some related ones and HCI in general: Bret Victor: The Future of Programming
-
God, I have been trying to recall the name of this talk for ages! Thank you so much, it is a great recommendation
-
-
Text is great when (not if) your more complicated tools fail or do something you can’t tolerate and you need to use tools which don’t Respect The Intent of designers who, for whatever reason, don’t respect your intent or workflow. Sometimes, solving a problem means working around a breakage, whether or not that breakage is intentional on someone else’s part.
Besides, we just (like, last fifteen or so years) got text to the point where it’s largely compatible. Would be a shame to throw that away in favor of some new AST-database-thing which only exists on a few platforms.
-
I’m not sure I get your point about about intent. Isn’t the same already true of, say, compilers? There are compiler bugs that we have to work around, there are programs that seem logical to us but the compiler won’t accept, and so on. Still, everybody seems to be mostly happy to file a compiler bug or a feature request, and live with a workaround for the present. Seems like it works well enough in practice.
I understand your concern about introducing a new format but it sounds like a case of worse-is-better. Sure, we get a lot of convenience from the ubiquity of text, but it would nevertheless be sad if we were stuck with it for the next two centuries.
-
-
I’ve never seen anyone casually swap out the compiler for production code. Also, for the longest time, if you wrote C++ for Windows, you pretty much had to use the Microsoft compiler. I’m sure that there are many embedded platforms with a single compiler.
If there’s a bug in the compiler, in most casss you work around it, then patiently wait for a fix from the vendor.
So that’s hardly a valid counterpoint.
-
-
Yes, I’m aware of that, but what does it have to do with anything I said?
EDIT: Hey, I went to Canterbury :)
-
“I’ve never seen anyone casually swap out the compiler for production code” sounded like you were saying people didn’t tend to compile the same production code on multiple compilers, which of course anyone that compiles on windows and non-windows does. Sorry if I misinterpreted your comment!
My first comment is in response to another Kiwi. Small world. Pretty cool.
-
-
-
-
-
-
-
This, this, a thousand times this. Text is a good user-interface for code (for now). But it’s a terrible storage and interchange format. Every tool needs its own parser, and each one is slightly different, leaving begging the amount of cpu and programmer time we waste going from text<->ast<->text.
-
Yeah, it’s obviously wasteful and limiting. Why do you think we are still stuck with text? Is it just sheer inertia and incrementalism, or does text really offer advantages that are challenging to recreate with other formats?
-
The text editor I use can handle any computer language you can throw at it. It doesn’t matter if it’s BASIC, C, BCPL, C++, SQL, Prolog, Fortran 77, Pascal, x86 Assembler, Forth, Lisp, JavaScript, Java, Lua, Make, Hope, Go, Swift, Objective-C, Rexx, Ruby, XSLT, HTML, Perl, TCL, Clojure, 6502 Assembler, 68000 Assembler, COBOL, Coffee, Erlang, Haskell, Ocaml, ML, 6809 Assembler, PostScript, Scala, Brainfuck, or even Whitespace. [1]
Meanwhile, the last time I tried an IDE (last year I think) it crashed hard on a simple C program I attempted to load into it. It was valid C code [2]. That just reinforced my notion that we aren’t anywhere close to getting away from text.
[1] APL is an issue, but only because I can’t type the character set on my keyboard.
[2] But NOT C++, which of course, everybody uses, right?
-
To your point about text editors working with any language, I think this is like arguing that the only tool required by a carpenter is a single large screwdriver: you can use it as a hammer, as a chisel, as a knife (if sharpened), as a wedge, as a nail puller, and so on. Just apply sufficient effort and ingenuity! Does that sound like an optimal solution?
My preference is for powerful specialised tools rather than a single thing that can be kind of sort of applied to a task.
Or, to approach from the opposite direction, would you say that a CAD application or Blender are bad tools because they only work with a limited number of formats? If only they also allowed you to edit JPEGs and PDFs, they would be so much better!
To your point about IDEs: I think that might even support my argument. Parsing of freeform text is apparently sufficiently hard that we’re still getting issues like the one you saw.
-
I use other tools besides the text editor—I use version control, compilers, linkers, debuggers, and a whole litany of Unix tools (grep, sed, awk, sort, etc). The thing I want to point out is that as long as the source code is in ASCII (or UTF-8), I can edit it. I can study it. I might not be able to compile it (because I lack the INRAC compiler but I can still view the code). How does one “view” Smalltalk code when one doesn’t have Smalltalk? Or Visual Basic? Last I hear, Microsoft wasn’t giving out the format for Visual Basic programs (and good luck even finding the format for VB from the late 90s).
The other issue I have with IDEs (and I will come out and say I have a bias against the things because I’ve never had one that worked for me for any length of time without crashing, and I’ve tried quite a few over 30 years) is that you have one IDE for C++, and one for Java, and one for Pascal, and one for Assembly [1] and one for Lua and one for Python and man … that’s just too many damn environments to deal with [2]. Maybe there are IDEs now that can work with more than one language [3] but again, I’ve yet to find one that works.
I have nothing against specialized tools like AutoCAD or Blender or PhotoShop or even Deluxe Paint, as long as there is a way to extract the data when the tool (or the company) is no longer around. Photo Shop and Deluxe Paint work with defined formats that other tools can understand. I think Blender works with several formats, but I am not sure about AutoCAD (never having used it).
So, why hasn’t anyone stored and manipulated ASTs? I keep hearing cries that we should do it, but yet, no one has yet done it … I wonder if it’s harder than you even imagine …
Edited to add: Also, I’m a language maven, not a tool maven. It sounds like you are a tool maven. That colors our perspectives.
[1] Yes, I’ve come across several of those. Never understood the appeal …
[2] For work, I have to deal with C, C++, Lua, Make and Perl.
[3] Yeah, the last one that claimed C/C++ worked out so well for me.
-
For your first concern about the long term accessibility of the code, you’ve already pointed out the solution: a defined open format.
Regarding IDEs: I’m not actually talking about IDEs; I’m talking about an editor that works with something other than text. Debugging, running the code, profiling etc. are different concerns and they can be handled separately (although again, the input would be something other than text). I suppose it would have some aspects of an IDE because you’d be manipulating the whole code base rather than individual files.
Regarding the language maven post: I enjoyed reading it a few years ago (and in practice, I’ve always ended up in the language camp as an early adopter). It was written 14 years ago, and I think the situation is different now. People have come to expect tooling, and it’s much easier to provide it in the form of editor/IDE plugins. Since language creators already have to do a huge amount of work to make programs in their languages executable in some form, I don’t think it would be an obstacle if the price of admission also included dealing with the storage format and representation.
To your point about lack of implementations: don’t Smalltalk and derivatives such as Pharo qualify? I don’t know if they store ASTs but at least they don’t store text. I think they demonstrate that it’s at least technically possible to get away from text, so the lack of mainstream adoption might be caused by non-technical reasons like being in a local maximum in terms of tools.
The problem, as always, is that there is such a huge number of tools already built around text that it’s very difficult to move to something else, even if the post-transition state of affairs would be much better.
-
Text editors are language agnostic.
I’m trying to conceive of an “editor” that works with something other than text. Say an AST. Okay, but in Pascal, you have to declare variables at the top of each scope; you can declare variables anywhere in C++. In Lua, you can just use a variable, no declaration required. LISP, Lua and JavaScript allow anonymous functions; only the latest versions of C++ and Java allow anonymous functions, but they they’re restricted in that you can’t create closures, since C++ and Java have no concept of closures. C++ has exceptions, Java has two types of exceptions, C doesn’t; Lua kind of has exceptions but not really. An “AST editor” would have to somehow know that is and isn’t allowed per language, so if I’m editing C++ and write an anonymous function, I don’t reference variables outside the scope of said function, but that it can for Lua.
Okay, so we step away from AST—what other format do you see as being better than text?
-
I don’t think it could be language agnostic - it would defeat the purpose as it wouldn’t be any more powerful than existing editors. However, I think it could offer largely the same UI, for similar languages at least.
-
And that is my problem with it. As stated, I use C, C++ [1], Lua, Make and a bit of Perl. That’s at least what? Three different “editors” (C/C++, Lua/Perl (maybe), Make). No thank you, I’ll stick with a tool that can work with any language.
[1] Sparingly and where we have no choice; no one on my team actually enjoys it.
-
-
Personally, I’m not saying you should need to give up your editor of choice. Text is a good (enough for now) UI for coding. But it’s a terrible format to build tools on. If the current state of the code lived in some sort of event-based graph database for example, your changes could trigger not only your incremental compiler, but source analysis (only on what’s new), it could also maintain a semantic changelog for version control, trigger code-generation (again, only what’s new).
There’s a million things that are currently “too hard” which would cease to be too hard if we had a live model of the code as various graphs (not just the ast, but call graphs, inheritance graphs, you-name-it) that we could subscribe to, or even write purely-functional consumers that are triggered only on changes.
-
-
-
-
-
-
Inertia, arrogance, worse-is-better; Working systems being trapped behind closed doors at big companies; Hackers taking their language / editor / process on as part of their identity that needs to be defended with religious zeal; The complete destruction of dev tools as a viable business model; Methodologies-of-the-week…. The causes are numerous and varied, and the result is software dev is being hamstrung and we’re all wasting countless hours and dollars doing things computers should be doing for us.
-
I think that part of the issue is that we haven’t seen good structured editor support outside of Haskell and some Lisps.
Having a principled foundation for structured editor + a critical mass by having it work for a language like Javascript/Ruby, would go a long way to making this concept more mainstream. After which we could say “provide a grammar for favorite language X and get structured editor support!”. This then becomes “everything is structured at all levels!”
-
I think it’s possible that this only works for a subset of languages.
Structured editing is good in that it operates at a higher level than characters, but ultimately it’s still a text editing tool, isn’t it? For example, I think it should be trivial to pull up a list of (editable) definitions for all the functions in a project that call a given function, or to sort function and type definitions in different ways, or to substitute function calls in a function with the bodies of those functions to a given depth (as opposed to switching between different views to see what those functions do). I don’t think structured editing can help with tasks like that.
There are also ideas like Luna, have you seen it? I’m not convinced by the visual representation (it’s useful in some situations but I’m not sure it’s generally effective), but the interesting thing is they provide both a textual and a visual representation of the code.
-
-
-
-
-
Smalltalk. The word you’re looking for is Smalltalk. ;)
-
-
Possibly, but I’m only talking about a single aspect of it: being able to analyse and manipulate the code in more powerful ways than afforded by plain text. I think that’s equally possible for FP languages.
-
-
-
Ultimately I think this is the only teneble solution. I feel I must be in the minority in having an extreme dislike of columnar-style code, and what I call “white space cliffs” where a column dictates a sudden huge increase in whitespace. But I realize how much it comes down to personal aesthetics, so I wish we could all just coexist :)
-
Yeah, I’ve been messing around with similar ideas, see https://nick.zoic.org/art/waste-web-abstract-syntax-tree-editor/ although it’s only vapourware so far because things got busy …
-
-
You can’t convert to elastic-tabstop style from that, and without heavy language-grammar knowledge you can’t do this for 4-space “tabs” generally.
Every editor ever supports this for traditional indent style, though: http://intellindent.info/seriously/
-
To be clear, you can absolutely render a file that doesn’t have elastic tabstops as if it did. The way a file is rendered has nothing to do with the actual text in the file.
It’s like you’re suggesting that you can’t render a file containing a ton of numbers as a 3D scene in a game engine. That would be just wrong.
Regardless, my point is specifically that this elastic tabstops thing is not necessary and hurts code readability more than it helps.
The pefantics of clarifying between tabs and tabstops is a silly thing as well. Context gives more than enough information to know which one is being talked about.
It sounds like this concept is creating more problems than it solves, and is causing your editor to solve problems that only exist in the seveloper’s imagination. It’s not “KISS” at all, quite the opposite.
-
-
-
Because presentation isn’t just a function of the AST. Indentation usually is, but alignment can be visually useful for all kinds of reasons.
-
-
I didn’t know what was Gopher before and still not sure what it is (will read more on that). I find Lobster already a pretty good interface without much distraction since it’s mostly text, so I don’t know what I would really use it for. What would be the use of this over lobster?
Nice work and it’s loads really fast.
-
Gopher is an old protocol, I mean it predates the world wide web so it’s not about making an alternative UI to lobste.rs on http:// but on gopher:// for people who like to live in a plain-text world. See https://gopher.floodgap.com/overbite/relevance.html for more informations on gopher.
-
live in a plain-text world
Except that gopher doesn’t guarantee plain-text (in practise any file type can be served). IIRC the main advantage of Gopher is that it has a standard format for navigation.
-
Interestingly enough, Gopher and the web are roughly the same age - Gopher was publicly released in 1991, the same year as Tim Berners-Lee’s original announcement to
alt.hypertext.
-
-
-
It’s interesting because the author is not thoughtlessly in favour of GitHub, but I think that his rebuttals are incomplete and ultimate his point is incorrect.
Code changes are proposed by making another Github-hosted project (a “fork”), modifying a remote branch, and using the GUI to open a pull request from your branch to the original.That is a bit of a simplification, and completely ignores the fact that GitHub has an API. So does GitLab and most other similar offerings. You can work with GitHub, use all of its features, without ever having to open a browser. Ok, maybe once, to create an OAuth token.
Whether using the web UI or the API, one is still performing the quoted steps (which notably never mention the browser).
A certain level of discussion is useful, but once it splits up into longer sub-threads, it becomes way too easy to loose sight of the whole picture.
That’s typically the result of a poor email client. We’ve had threaded discussions since at least the early 90s, and we’ve learned a lot about how to present them well. Tools such as gnus do a very good job with this — the rest of the world shouldn’t be held back because some people use poor tools.
Another nice effect is that other people can carry the patch to the finish line if the original author stops caring or being involved.On GitHub, if the original proposer goes MIA, anyone can take the pull request, update it, and push it forward. Just like on a mailing list. The difference is that this’ll start a new pull request, which is not unreasonable: a lot of time can pass between the original request, and someone else taking up the mantle. In that case, it can be a good idea to start a new thread, instead of resurrecting an ancient one.
What he sees as a benefit I see as a detriment: the new PR will lose the history of the old PR. Again, I think this is a tooling issue: with good tools resurrecting an ancient thread is just no big deal. Why use poor tools?
While web apps deliver a centrally-controlled user interface, native applications allow each person to customize their own experience.GitHub has an API. There are plenty of IDE integrations. You can customize your user-experience just as much as with an email-driven workflow. You are not limited to the GitHub UI.
This is somewhat disingenuous: while GitHub does indeed have an API, the number & maturity of GitHub API clients is rather less than the number & maturity of SMTP+IMAP clients. We’ve spent about half a century refining the email interface: it’s pretty good.
Granted, it is not an RFC, and you are at the mercy of GitHub to continue providing it. But then, you are often at the mercy of your email provider too.
There’s a huge difference between being able to easily download all of one’s email (e.g. with OfflineIMAP) and only being at the mercy of one’s email provider going down, and being at the mercy of GitHub preserving its API for all time. The number of tools which exist for handling offline mail archives is huge; the number of tools for dealing with offline GitHub project archives is … small. Indeed, until today I’d have expected it to be almost zero.
Github can legally delete projects or users with or without cause.Whoever is hosting your mailing list archives, or your mail, can do the same. It’s not unheard of.
But of course my own maildir on my own machine will remain.
I use & like GitHub, and I don’t think email is perfect. I think we’re quite aways from the perfect git UI — but I’m fairly certain that it’s not a centralised website.
-
We’ve spent about half a century refining the email interface: it’s pretty good.
We’ve spent about half a century refining the email interface. Very good clients exist…. but most people still use GMail regardless.
-
That’s typically the result of a poor email client. We’ve had threaded discussions since at least the early 90s, and we’ve learned a lot about how to present them well. Tools such as gnus do a very good job with this — the rest of the world shouldn’t be held back because some people use poor tools.
I have never seen an email client that presented threaded discussions well. Even if such a client exists, mailing-list discussions are always a mess of incomplete quoting. And how could they not be, when the whole mailing list model is: denormalise and flatten all your structured data into a stream of 7-bit ASCII text, send a copy to every subscriber, and then hope that they’re able to successfully guess what the original structured data was.
You could maybe make a case for using an NNTP newsgroup for project discussion, but trying to squeeze it through email is inherently always going to be a lossy process. The rest of the world shouldn’t be held back because some people use poor tools indeed - that means not insisting that all code discussion has to happen via flat streams of 7-bit ASCII just because some people’s tools can’t handle anything more structured.
I agree with there being value in multipolar standards and decentralization. Between a structured but centralised API and an unstructured one with a broader ecosystem, well, there are arguments for both sides. But insisting that everything should be done via email is not the way forward; rather, we should argue for an open standard that can accommodate PRs in a structured form that would preserve the very real advantages people get from GitHub. (Perhaps something XMPP-based? Perhaps just a question of asking GitHub to submit their existing API to some kind of standards-track process).
-
You could maybe make a case for using an NNTP newsgroup for project discussion
While I love NNTP, the data format is identical to email, so if you think a newsgroup can have nice threads, then so could a mailing list. They’re just different network distribution protocols for the same data format.
accommodate PRs in a structured form
Even if you discount structured text, emails and newsgroup posts can contain content in any MIME type, so a structured PR format could ride along with descriptive text in an email just fine.
-
Even if you discount structured text, emails and newsgroup posts can contain content in any MIME type, so a structured PR format could ride along with descriptive text in an email just fine.
Sure, but I’d expect the people who complain about github would also complain about the use of MIME email.
-
-
You could maybe make a case for using an NNTP newsgroup for project discussion, but trying to squeeze it through email is inherently always going to be a lossy process.
Not really — Gnus has offered a newsgroup-reader interface to email for decades, and Gmane has offered actual NNTP newsgroups for mailing lists for 16 years.
But insisting that everything should be done via email is not the way forward; rather, we should argue for an open standard that can accommodate PRs in a structured form that would preserve the very real advantages people get from GitHub. (Perhaps something XMPP-based? Perhaps just a question of asking GitHub to submit their existing API to some kind of standards-track process).
I’m not insisting on email! It’s decent but not great. What I would insist on, were I insisting on anything, is real decentralisation: issues should be inside the repo itself, and PRs should be in some sort of pararepo structure, so that nothing more than a file server (whether HTTP or otherwise) is required.
-
-
…the new PR will lose the history of the old PR.
Why not just link to it?
This is somewhat disingenuous: while GitHub does indeed have an API, the number & maturity of GitHub API clients is rather less than the number & maturity of SMTP+IMAP clients. We’ve spent about half a century refining the email interface: it’s pretty good.
That strikes me as disingenuous as well. Email is older. Of course it has more clients, with varying degrees of maturity & ease of use. That has no bearing on whether the GitHub API or an email-based workflow is a better solution. Your point is taken; the GitHub API is not yet “Just Add Water!”-tier. But the clients and maturity will come in time, as they do with all well-used interfaces.
Github can legally delete projects or users with or without cause.
Whoever is hosting your mailing list archives, or your mail, can do the same. It’s not unheard of.
But of course my own maildir on my own machine will remain.
Meanwhile, the local copy of my git repo will remain.
I think we’re quite aways from the perfect git UI — but I’m fairly certain that it’s not a centralised website.
I’m fairly certain that it’s a website of some sort—that is, if you intend on using a definition of “perfect” that scales to those with preferences & levels of experience that differ from yours.
-
Meanwhile, the local copy of my git repo will remain.
Which contains no issues, no discussion, no PRs — just the code.
I’d like to see a standard for including all that inside or around a repo, somehow (PRs can’t really live in a repo, but maybe they can live in some sort of meta- or para-repo).
I’m fairly certain that it’s a website of some sort—that is, if you intend on using a definition of “perfect” that scales to those with preferences & levels of experience that differ from yours.
Why on earth would I use someone else’s definition? I’m arguing for my position, not someone else’s. And I choose to categorically reject any solution which relies on a) a single proprietary server and/or b) a JavaScript-laden website.
-
Meanwhile, the local copy of my git repo will remain.
Which contains no issues, no discussion, no PRs — just the code.
Doesn’t that strike you as a shortcoming of Git, rather than GitHub? I think this may be what you are getting at.
Why on earth would I use someone else’s definition?
Because there are other software developers, too.
I choose to categorically reject any solution which relies on a) a single proprietary server and/or b) a JavaScript-laden website.
I never said anything about reliance. That being said, I think the availability of a good, idiomatic web interface is a must nowadays where ease-of-use is concerned. If you don’t agree with that, then you can’t possibly understand why GitHub is so popular.
-
-
-
(author here)
Whether using the web UI or the API, one is still performing the quoted steps
Indeed, but the difference between using the UI and the API, is that the latter is much easier to build tooling around. For example, to start contributing to a random GitHub repo, I need to do the following steps:
- Tell my Emacs to clone & fork it. This is as simple as invoking a shortcut, and typing or pasting the upstream repo name. The integration in the background will do the necessary forking if needed. Or I can opt not to fork, in which case it will do it automatically later.
- Do the changes I want to do.
- Tell Emacs to open a pull request. It will commit my changes (and prompt for a commit message), create the branch, and open a PR with the same commit message. I can use a different shortcut to have more control over what my IDE does, name the branch, or create multiple commits, etc.
It is a heavily customised workflow, something that suits me. Yet, it still uses GitHub under the hood, and I’m not limited to what the web UI has to offer. The API can be built upon, it can be enriched, or customised to fit one’s desires and habits. The difference in what I need to do to get the same steps done differs drastically. Yes, my tooling does the same stuff under the hood - but that’s the point, it hides those detail from me!
(which notably never mention the browser).
Near the end of the article I replied to:
“Tools can work together, rather than having a GUI locked in the browser.”
From this, I concluded that the article was written with the GitHub web UI in mind. Because the API composes very well with other tools, and you are not locked into a browser.
That’s typically the result of a poor email client.
I used Gnus in the past, it’s a great client. But my issue with long threads and lots of branches is not that displaying them is an issue - it isn’t. Modern clients can do an amazing job making sense of them. My problem is the cognitive load of having to keep at least some of it in mind. Tools can help with that, but I can only scale so far. There are people smarter than I who can deal with these threads, I prefer not to.
What he sees as a benefit I see as a detriment: the new PR will lose the history of the old PR. Again, I think this is a tooling issue: with good tools resurrecting an ancient thread is just no big deal. Why use poor tools?
The new PR can still reference the old PR, which is not unlike having an
In-Reply-Toheader that points to a message not in one’s archive. It’s possible to build tooling on top of this that would go and fetch the original PR for context.Mind you, I can imagine a few ways the GitHub workflow could be improved, that would make this kind of thing easier, and less likely to loose history. I’d still rather have an API than e-mail, though.
This is somewhat disingenuous: while GitHub does indeed have an API, the number & maturity of GitHub API clients is rather less than the number & maturity of SMTP+IMAP clients. We’ve spent about half a century refining the email interface: it’s pretty good.
Refining? You mean that most MUAs look just like they did thirty years ago? There were many quality of life improvements, sure. Lots of work to make them play better with other tools (this is mostly true for tty clients and Emacs MUAs, as far as I saw). But one of the most wide-spread MUA (gmail) is absolutely terrible when it comes to working with code and mailing lists. Same goes for Outlook. The email interface story is quite sad :/
There’s a huge difference between being able to easily download all of one’s email (e.g. with OfflineIMAP) and only being at the mercy of one’s email provider going down, and being at the mercy of GitHub preserving its API for all time.
Yeah, there are more options to back up your mail. It has been around longer too, so that’s to be expected. Email is also a larger market. But there are a reasonable number of tools to help backing up one’s GitHub too. And one always makes backups anyway, just in case, right?
So yeah, there is a difference. But both are doable right now, with tools that already exist, and as such, I don’t see the need for such a fuss about it.
I use & like GitHub, and I don’t think email is perfect. I think we’re quite aways from the perfect git UI — but I’m fairly certain that it’s not a centralised website.
I don’t think GitHub is anywhere near perfect, especially not when we consider that it is proprietary software. It being centralised does have advantages however (discoverability, not needing to register/subscribe/whatever to N+1 places, and so on).
-
-
I love the “do not work as currencies” quote that people love to say… I’ve been using cryptocurrencies to buy products and services for years. Seems to work fine.
-
When I skimmed it, the paper was more specific about what doesnt work means. Wild shifts in value causing more holding than spending was one example. That’s also why every person I know IRL who does Bitcoin is a speculator or day trader.
-
-
I think the title is misleading. He just talks about Bitcoin and proof-of-work, but calls it “Risks of Cryptocurrencies”. If the title would be “The Risk of Bitcoin”, fair enough. The only purpose of Bitcoin is now to bring money from investors into the gamble, and the distribute the money onto other projects until there is one which figures out how to make blockchain-based currencies work.
I disagree that we should just give up on the idea. Imo, crypto currencies would let anybody take part of the system “capitalism” and therefore could improve it much faster and easier. Right now, to invest in a company, I need to go through a third party. Other investments are almost not doable for a working class person.
in my perfect world, every Dollar would be on the Blockchain, we have then much better tools to diagnose and monitor it and make it visible what’s going on. And then, slowly, we can distribute wealth to products and people who are doing more good then harm.
For this to work, of course, we need to improve crypto currencies (proof-of-* etc.) A LOT. But all I read is people complaining about the amount of money people put into Bitcoin, yet nobody sees how much money travels every day via the stock exchanges.
So yes, get the rich investors hyped, put their money onto the blockchain, use it to create better systems and then monitor money flows and direct money to better products and ideas.
-
The only purpose of Bitcoin is now to bring money from investors into the gamble
… and also to, you know, pay for products and services.
-
crypto currencies would let anybody take part of the system “capitalism” and therefore could improve it much faster and easier
So far, that “anybody” has been scammers, ransomware authors and other criminals. I’m not sure how “investing” in literal Ponzi schemes improves anything.
to invest in a company, I need to go through a third party
What’s wrong with that? The third party is legally responsible for the stuff. You can’t sue a trustless p2p ledger for accidentally burning your money.
-
-
Git via email sounds like hell to me. I’ve tried to find some articles that evangelize the practice of doing software development tasks through email, but to no avail. What is the allure of approaches like this? What does it add to just using
gitby itself?-
I tried to collect the pros and cons in this article: https://begriffs.com/posts/2018-06-05-mailing-list-vs-github.html
-
I also spoke about this at length in a previous article:
-
While my general experience with git email is bad (it’s annoying to set up, especially in older versions and I don’t like it’s interface too much), my experience of interaction with projects that do this was generally good. You send a patch, you get review, you send a new, self-contained patch, attached to the same thread… etc, in parallel to the rest of the project discussion. It’s a different flavour, but with a project that is used to the flow, it can really be quite pleasing.
-
What does it add to just using git by itself?
I think the selling point is precisely that it doesn’t add anything else. Creating a PR involves more steps and context changes than git-format-patch git-send-mail.
I have little experience using the mailing list flow, but when I had to do so (because the project required it) I found it very easy to use and better for code reviews.
-
-
Simply, it’s “create a fork and push your changes to it”. But also consider that it’s…
- Open a web browser
- Register for a GitHub account
- Confirm your email address
- Fork the repository
- Push your changes to the fork
- Open a pull request
In this workflow, you switched between your terminal, browser, mail client, browser, terminal, and browser before the pull request was sent.
With git send-email, it’s literally just
git send-email HEAD^to send the last commit, then you’re prompted for an email address, which you can obtain from git blame or the mailing list mentioned in the README. You can skip the second step next time by doinggit config sendemail.to someone@example.org. Bonus: no proprietary software involved in the send-email workflow.-
Also github pull requests involve more git machinery than is necessary. Most people, when they open a PR, choose to make a feature branch in their fork from which to send the PR, rather than sending from master. The PR exposes the sender’s local branching choices unnecessarily. Then, for each PR, github creates more refs on the remote, so you end up having lots stuff laying around (try running
git ls-remote | grep pull).Compare that with the idea that if you want to send a code change, just mail the project a description (diff) of the change. We all must be slightly brainwashed when that doesn’t seem like the most obvious thing to do.
In fact the sender wouldn’t even have to use git at all, they could download a recent code tarball (no need to clone the whole project history), make changes and run the diff command… Might not be a great way to do things for ongoing contributions, but works for a quick fix.
Of course opening the PR is just the start of the future stymied github interactions.
-
In my case I tend to also perform steps:
- 3.1 Clone project
- 3.2 Use project for a while
- 3.3 Make some local changes
- 3.4 Commit those changes to local clone
- 3.5 Try to open pull request
- 3.6 Realise GitHub requires me to make a fork of the original repo
- 4.1 Read
man git-remoteto see how to point my local clone (with the changes) to my GitHub fork - 4.2 Run relevant
git remotecommands - 4.3 Read
man git-pushto see how to send my changes to the fork rather than the original repo
-
To send email, you also have to have an email address. If we are doing a fair comparison, that should be noted as well. Granted, it is much more likely that someone has an email address than a GitHub account, but the wonderful thing about both is that you only have to set them up once. So for this reason, it would be a bit more fair if the list above started from step four.
Now, if I have GitHub integration in my IDE (which is not an unreasonable thing to assume), then I do not need to leave the IDE at all, and I can fork, push, and open a PR (case in point, Emacs and Magithub can do this). I can also do all of this on GitHub, never leaving my browser. I don’t have to figure out where to send an email, because it automatically sends the PR to the repo I forked from. I don’t even need to open a shell and deal with the commandline. I can do everything with shortcuts and a little bit of mousing around, in both the IDE and the browser case.
Even as someone who is familiar with the commandline, and is sufficiently savvy with e-mail (at one point I was subscribed to debian-bugs-dist AND LKML, among other things, and had no problem filtering out the few bits I needed), I’d rather work without having to send patches, using Magit + magithub instead. It’s better integrated, hides uninteresting details from me, so I can get done with my work faster. It works out of the box.
git send-emaildoes not, it requires a whole lot of set up per repo.Furthermore, with e-mail, you have to handle replies, have a firm grip on your inbox. That’s an art on its own. No such issue with GitHub.
With this in mind, the remaining benefit of
git send-emailis that it does not involve a proprietary platform. For a whole lot of people, that’s not an interesting property.-
To send email, you also have to have an email address. If we are doing a fair comparison, that should be noted as well.
I did note this:
then you’re prompted for an email address, which you can obtain from git blame or the mailing list mentioned in the README
Magit + magithub […] works out of the box
Only if you have a GitHub account and authorize it. Which is a similar amount of setup, if not more, compared to setting up git send-email with your SMTP info.
git send-email does not, it requires a whole lot of set up per repo
You only have to put your SMTP creds in once. Then all you have to do per-repo is decide where to send the email to. How is this more work than making a GitHub fork? All of this works without installing extra software to boot.
-
then you’re prompted for an email address, which you can obtain from git blame or the mailing list mentioned in the README
With GitHub, I do not need to obtain any email address, or dig it out of a README. It sets things up automatically for me so I can just open a PR, and have everything filled out.
Only if you have a GitHub account and authorize it. Which is a similar amount of setup, if not more, compared to setting up git send-email with your SMTP info.
Lets compare:
e-mail:
- Clone repository
- Do my business
- Figure out where to send e-mail to.
- git config so I won’t have to figure it out ever again.
- git send-email
magithub:
- clone repo
- do my business
- fork the repo
- push changes
- open PR
The first two steps are pretty much the same, both are easily assisted by my IDE. The difference starts from step 3, because my IDE can’t figure out for me where to send the email. That’s a manual step. I can create a helper that makes it easier for me to do step 4 once I have the address, but that’s about it. For the magithub case, step 3 is
SPC g h f; step 4SPC g s p u RET; step 5SPC g h p, then edit the cover letter, and, c(orC-c) to finish it up and send it. You can use whatever shortcuts you set up, these are mine. Nothing to figure out manually, all automated. All I have to do is invoke a shortcut, edit the cover letter (the PR’s body), and I’m done.I can even automate the clone + fork part, and combine push changes + open PR, so it becomes:
- fork & clone repo (or clone if already forked)
- do my business
- push changes & open PR
Can’t do such automation with e-mailed patches.
I’m not counting GitHub account authorization, because that’s about the same complexity as configuring auth for my SMTP, and both have to be done only once. I’m also not counting registering a GitHub account, because that only needs to be done once, and you can use it forever, for any GitHub-hosted repo, and takes about a minute, a miniscule amount compared to doing actual development.
Again, the main difference is that for the e-mail workflow, I have to figure out the e-mail address, a process that’s longer than forking the repo and pushing my changes, and a process that can’t be automated to the point of requiring a single shortcut.
Then all you have to do per-repo is decide where to send the email to. How is this more work than making a GitHub fork?
Creating a GitHub fork is literally one shortcut, or one click in the browser. If you can’t see how that is considerably easier than digging out email addresses from free-form text, then I have nothing more to say.
And we haven’t talked about receiving comments on the email yet, or accepting patches. Oh boy.
-
With GitHub, I do not need to obtain any email address, or dig it out of a README. It sets things up automatically for me so I can just open a PR, and have everything filled out.
You already had to read the README to figure out how to compile it, and check if there was a style guide, and review guidelines for contribution…
Lets compare
Note that your magithub process is the same number of steps but none of them have “so I won’t have to figure it out ever again”, which on the email process actually eliminates two of your steps.
Your magithub workflow looks much more complicated, and you could use keybindings to plug into send-email as well.
Can’t do such automation with e-mailed patches
You can do this and even more!
-
You already had to read the README to figure out how to compile it, and check if there was a style guide, and review guidelines for contribution…
I might have read the README, or skimmed it. But not to figure out how to compile - most languages have a reasonably standardised way of doing things. If a particular project does not follow that, I will most likely just stop caring unless I really, really need to compile it for one reason or another. For style, I hope they have tooling to enforce it, or at least check it, so I don’t have to read long documents and keep it in my head. I have more important things to store there than things that should be automated.
I would likely read the contributing guidelines, but I won’t memorize it, and I certainly won’t try to remember an e-mail address. I might remember where to find it, but it will still be a manual process. Not a terribly long process, but noticeably longer than not having to do it at all.
Note that your magithub process is the same number of steps but none of them have “so I won’t have to figure it out ever again”, which on the email process actually eliminates two of your steps.
Because there’s nothing for me to figure out at all, ever (apart from what repo to clone & fork, but that’s a common step between the two workflows).
Your magithub workflow looks much more complicated
How is it more complicated? Clone, work, fork, push, open PR (or clone+fork, work, push+PR), of which all but “work” is heavily assisted. None of it requires me to look anything up, anywhere.
and you could use keybindings to plug into send-email as well.
And I do, when I’m dealing with projects that use an e-mail workflow. It’s not about shortcuts, but what can be automated, what the IDE can do instead of requiring me to do it.
You can do this and even more!
You can, if you can extract the address to send patches to automatically. You can build something that does that, but then the automation is tied to that platform, just like the PRs are tied to GitHub/GitLab/whatever.
And again, this is just about sending a patch/opening a PR. There’s so much more PRs provide than that. Some of that, you can do with e-mail. Most of it, you can build on top of e-mail. But once you build something on top of e-mail, you no longer have an e-mail workflow, you have a different platform with which you can interact via e-mail. Think issues, labels for them, reviews (with approvals, rejection, etc - all of which must be discoverable by programs reliably), new commits, rebases and whatnot… yeah, you can build all of this on top of e-mail, and provide a web UI or an API or tools or whatever to present the current state (or any prior state). But then you built a platform which requires special tooling to use to its full potential, and you’re not much better than GitHub. You might build free software, but then there’s GitLab, Gitea, Gogs and a whole lot of others which do many of these things already, and are almost as easy to use as GitHub.
I’ve worked with patches sent via e-mail quite a bit in the past. One can make it work, but it requires a lot of careful thought and setup to make it convenient. I’ll give a few examples!
With GitHub and the like, it is reasonably easy to have an overview of open pull requests, without subscribing to a mailing list, or browsing archives. An open PR list is much easier to glance at and have a rough idea than a mailing list. PRs can have labels to help in figuring out what part of the repo they touch, or what state they are in. They can have CI states attached. At a glance, you get a whole lot of information. With a mailing list, you don’t have that. You can build something on top of e-mail that gives you a similar overview, but then you are not using e-mail only, and will need special tooling to process the information further (eg, to limit open PRs to those that need a review, for example).
With GitHub and the like, you can subscribe to issues and pull requests, and you’ll get notifcations about those and those alone. With a mailing list, you rarely have that option, and must do filtering on your own, and hope that there’s a reasonable convention that allows you to do so reliably.
There’s a whole lot of other things that these tools provide over plain patches over email. Like I said before, most - if not all - of that can be built on top of e-mail, but to achieve the same level of convenience, you will end up with an API that isn’t e-mail. And then you have Yet Another Platform.
-
How is it more complicated? Clone, work, fork, push, open PR (or clone+fork, work, push+PR)
Because the work for the send-email approach is: clone, work, git send-email. This is fewer steps and is therefore less complicated. Not to mention that as projects become more decentralized as they move away from GItHub, the registration process doesn’t go away and starts recurring for every new forge or instance of a forge you work with.
But once you build something on top of e-mail, you no longer have an e-mail workflow, you have a different platform with which you can interact via e-mail. Think issues, labels for them, reviews (with approvals, rejection, etc - all of which must be discoverable by programs reliably), new commits, rebases and whatnot…
Yes, that’s what I’m advocating for.
But then you built a platform which requires special tooling to use to its full potential, and you’re not much better than GitHub
No, I’m proposing all of this can be done with a very similar UX on the web and be driven by email underneath.
PRs can have labels to help in figuring out what part of the repo they touch, or what state they are in. They can have CI states attached.
So let’s add that to mailing list software. I explicitly acknoweldge the shortcomings of mail today and posit that we should invest in these areas rather than rebuilding from scratch without an email-based foundation. But none of the problems you bring up are problems that can’t be solved with email. They’re just problems which haven’t been solved with emails. Problems I am solving with emails. Read my article!
but then you are not using e-mail only, and will need special tooling to process the information further (eg, to limit open PRs to those that need a review, for example).
So what? Why is this even a little bit of a problem? What the hell?
With GitHub and the like, you can subscribe to issues and pull requests, and you’ll get notifcations about those and those alone.
You can’t subscribe to issues or pull requests, you have to subscribe to both, plus new releases. Mailing lists are more flexible in this respect. There are often separate thing-announce, thing-discuss (or thing-users), and thing-dev mailing lists which you can subscribe to separately depending on what you want to hear about.
Like I said before, most - if not all - of that can be built on top of e-mail, but to achieve the same level of convenience, you will end up with an API that isn’t e-mail.
No, you won’t. That’s simply not how this works.
Look, we’re just not on the same wavelength here. I’m not going to continue diving into this ditch of meaningless argument. You keep using whatever you’re comfortable with.
-
-
Your magithub workflow looks much more complicated, and you could use keybindings to plug into send-email as well.
I just remembered a good illustration that might explain my stance a bit better. My wife, a garden engineer, was able to contribute to a few projects during Hacktoberfest (three years in a row now), with only a browser and GitHub for Windows at hand. She couldn’t have done it via e-mail, because the only way she can use her email is via her smart phone, or GMail’s web interface. She knows nothing else, and is not interested in learning anything else either, because these perfectly suit her needs. Yet, she was able to discover projects (by looking at what I contributed to, or have starred), search for TODOs or look at existing issues, fork a repo, write some documentation, and submit a PR. She could have done it all from a web browser, but I set up GitHub for Windows for her - in hindsight, I should have let her just use the browser. We’ll do that this year.
She doesn’t know how to use the command-line, has no desire, and no need to learn it. Her email handling is… something that makes me want to scream (no filters, no labels, no folders - one big, unorganized inbox), but it suits her, and as such, she has no desire to change it in any way.
She doesn’t know Emacs, or any IDE for that matter, and has no real need for them, either.
Yet, her contributions were well received, they were useful, and some are still in place today, unchanged. Why? Because GitHub made it easy for newcomers to contribute. They made it so that contributing does not require them to use anything else but GitHub. This is a pretty strong selling point for many people, that using GitHub (and similar solutions) does not affect any other tool or service they use. It’s distinct, and separate.
-
Not all projects have work for unskilled contributors. Why should we cater to them (who on the whole do <1% of the work) at the expense of the skilled contributors? Particularly the most senior contributors, who in practice do 90% of the work. We don’t build houses with toy hammers so that your grandma can contribute.
I’m not saying we shouldn’t make tools which accomodate everyone. I’m saying we should make tools that accomodate skilled engineers and build simpler tools on top of that. Thus, the skilled engineers are not slowed down and the greener contributors can still get work done. Then, there’s a path for newer users to become more exposed to more powerful tools and more smoothly become senior contributors themselves.
You need to get this point down if you want me to keep entertaining a discussion with you: you can build the same easy-to-use UX and drive it with email.
-
I’m not saying we shouldn’t make tools which accomodate everyone. I’m saying we should make tools that accomodate skilled engineers and build simpler tools on top of that.
I was under the impression that git + GitHub are exactly these. Git and git send-email for those who prefer those style, GitHub for those who prefer that. The skilled engineers can use the powerful tools they have, while those with a different skillset can use GitHub. All you need is willingness to work with both.
you can build the same easy-to-use UX and drive it with email.
I’m not questioning you can build something very similar, but as long as e-mail is the only driving power behind it, there will be plenty of people who will turn to some other tool. Because filtering email is something you and I can easily do, but many can’t, or aren’t willing to. Not when there are alternatives that don’t require them to do extra work.
Mind you, I consider myself a skilled engineer, and I mainly use GitHub/GitLab APIs, because I don’t have to filter e-mail, nor parse the info in them, the API serves me data I can use in an easier manner. From an integrator point of view, this is golden. If, say, an Emacs integration starts with “Set up your email so mail with these properties are routed here”, that’s not a good user experience. And no, I don’t want to use my MUA to work with git, because magit is a much better, much more powerful tool for that, and I value my productivity.
-
I’m not questioning you can build something very similar, but as long as e-mail is the only driving power behind it, there will be plenty of people who will turn to some other tool.
I’m pretty sure the whole point would be that the “shiny UI” tool would not expose email to the user at all – so the “plenty of people” wouldn’t leave because they wouldn’t know the difference.
-
-
-
-
-
-
-
-
-
-
Using GitHub requires pushing to different repository and then opening the PR on the GitHub Interface, which is a context change. The git-send-mail would be equivalent to sending the PR.
git-send-email is only one step, akin to opening the PR, no need to push to a remote repository. And from the comfort of your development environment. (Emacs in my case)
-
-
-
-
- Bring them in for a few days, see if they can set up the dev environment, assign them some bugs nobody else wants to fix, have them meet everyone.
- Pay them.
- Decide if you want to keep paying them.
This is, of course, the obvious way to select people for any field, not just programming. The problem is that if you won’t do 6 then few candidates will want to do 5 (they can’t leave their job to come in for a few days) and companies seem allergic to 7 (which is essential for 6).
-
In the UK, it’s pretty common for new employees to start with a period of ‘probation’ (typically a few months, though it can vary), during which the notice period is much shorter (e.g. a week’s notice, for both sides), so there’s less commitment until the employer and employee are satisfied that they’re a good match. I suspect some companies don’t take full advantage of probation (i.e. they think of it as a backup in case they make a hiring mistake, rather than an opportunity to try someone they’re not sure about after interview), but some do.
-
You can’t explore with code, you can only build with it
This is not even remotely true
-
It is, for example, perfectly possible for pro-life and pro-choice advocates to collaborate on a software project. They just have to leave their opinions about abortion at the door, and this should not preclude them from freely sharing those opinions on social media without fear of disciplinary reprisal
I wonder if this is true. Richard Stallman said, regarding an abortion joke in glibc:
GNU is not a purely technical project, so the fact that this is not strictly and grimly technical is not a reason to remove this.
I asked this:
must one have the same political views as Stallman to be part of the GNU project? What if we simply believe in the four software freedoms, is that not enough? Should members who are against abortion be excluded?
and he replied to every single post in the thread except mine, so I don’t know what the answer is.
-
I wonder if this is true
It happens all the time in the general workplace. The South has one of the most heated histories you’ll find in things like race and gender issues. We mostly get along anywhere from tolerance to being friends. My government class was mostly split 50/50 on abortion debate with most staying friends after within days. Reading from people pushing CoC’s for political reasons, you’d think that was impossible. Yet, we do it every day in any places where peoples’ differences are tolerated. So, they’re wrong about that part. That simple.
The author’s concerns about discrimination are my concerns given I’ve watched almost every group in a dominant position down here reward members of their own group and discriminate against others. Non-whites or non-males were no exception. Their acts of racism and sexism just don’t make the news or waves on social media. Those that didn’t do this were rare, truly-inclusive folks that went out of their way to care about and understand people that were different. I love those people even if their beliefs or political moves piss me off at times. Many get along with or love me, too. I’ve learned a lot from them.
The tech industry, esp in Silicon Valley, is just strange to me vs what I normally encounter in general workplace. They seem to think only young, white males are capable of anything while preaching meritocracy and saying/doing anything without consequences. Then, the other haters, err activists, opposing them seem to think all white males are overprivileged people to minimize while giving opportunities and social dominance to every other group. Well, many of them even bring in just select groups (esp white women) ignoring other groups. Plus, carefully controlling speech and action in all forums with assumption every human is too weak to co-exist with those that disagree. With these factions, it’s as if there’s nothing else possible aside from these extremes despite massive number of counterexamples mostly outside of tech but also some in it. That includes the millions of minority members that seem to have a different opinion about minority or diversity issues.
Note: This is a tech site. I’m talking general trends. If you’re an exception, you know who you are. :)
So, I keep talking about it to try to shake people out of this binary, extremist thinking on opposite ends. For now, I don’t know what else to do given the beliefs are deeply social and emotional. That traditional and social media keeps putting them in bubbles seeing only people they’ll like the most or piss them off the most isn’t helping. One of best things I ever learned to do is keep people who oppose or aggravate me on social media. I watch their reactions to every hot topic, reading what evidence they post. Very enlightening. Plus, keep bringing the counterpoints in nice-as-I-can way to folks on the other side targeted to their perspective and terms rather than mine. Think on theirs carefully. I don’t what else to do about the herd or extremist mentalities many are about.
Btw rain1, I don’t know if you were back in time for the last thread on this but it was more interesting than most political ones. I experienced a jaw-dropping surprise or two there.
-
One of best things I ever learned to do is keep people who oppose or aggravate me on social media.
Be careful with this. Like cultists, an entire generation of pundits have developed that take advantage of psychological weaknesses we all possess. They use the “you have to listen to all sides!” argument to claim a right to your cognition, when doing so opens yourself to manipulation via framing or even simple repetition (and if these have emotional impact, like being aggravating, they’re more effective). Listening to many sides is in general very beneficial, so you have to constantly identify if the person is arguing in bad faith or not. This can be hard to do, and I won’t offer any strategies here because they tend to be extremely personal and subjective.
Critical thinking doesn’t make you immune to this. At the risk of using an engineering analogy, a logically secure input parser is still susceptible to denial of service. So keep your eyes open and try to get input from a variety of sources, but make sure you understand their biases and whether they’re arguing in bad faith or not.
-
“They use the “you have to listen to all sides!” argument to claim a right to your cognition, when doing so opens yourself to manipulation via framing or even simple repetition (and if these have emotional impact, like being aggravating, they’re more effective). “
This is a weak argument. You can always be tricked by any side, especially your own since you trust them more. The result is you still have to listen to different people. Further, you should look at evidence they present more than what you speculate about their biases, bad faith, etc. If evidence looks wrong or especially badly-intentioned, then you might start ignoring that person or group a bit more. You might still glance at their info in case something useful comes out. Totally ignore them when noise ratio is too high. That way, we get to your last sentence without censoring those that disagree with us based on bad assumptions about their motives or whatever. That’s often just ad hominem for political gain disguised as something reasonable.
Looking at the political stuff, the people on the left are often citing sources that are full of shit. The people on the right do that as well. I know each set of mainstream sources are intentionally biased trying to tell their audience what they want to hear to keep their advertising revenue up. For others, it might be book sales, numbers on social media, status/image, and so on. Then, there’s sources that are pretty honest with just human biases. They can get more dishonest if they get emotionally charged, though.
The irony of your warning is that you probably use some of those sources that are definitely operating in bad faith to support your political beliefs. I do, too, but that fits the model I just described of assuming everyone has error or agendas sifting the wheat from the chaff. For instance, I’ve read a Huffington Post article followed by a Ben Shapiro video on a topic since I knew both would have numbers useful to me. Then, I had to check every claim since both are full of shit. The good news is the bullshit itself is often repetitive since they aim for talking points that will spread virally. As in, the claims you have to fact check go down over time until getting good info out of semi-reliable sources is fairly efficient or not as bad at least.
-
For helping to filter out those acting in bad faith I found it helpful to sometimes ask yourself “what if they are right” and then research on the topic. Pulling up surveys, studies, essays, etc.
That does make you able to recognize these arguments more easily while also increasing your literacy and giving you ammunition.
Generally I think it’s most beneficial if people would ask themselves that more, esp. if they are in one of the political extremes. To try to imagine what the other side thinks and feels. Empathy and understanding are something the world lacks these days.
(Also be careful to not throw political centrists under the bus by simply throwing out “you have to listen to all sides”, we’re usually quite nice people even if we’re not always on your side!)
Of course, I also feel that the most important issue is that we learn to work together more. Plenty of people disagree politically on a number of issues and work together. That can be whether or not Fiber Internet should be subsidized or not up to much more controversial statements. I don’t think such disagreements are a reason not to work together. If they bring that sentiment to work and poison the team effort by splitting the team over it, then of course, stop working with them.
-
be careful to not throw political centrists under the bus by simply throwing out “you have to listen to all sides”
I’m saying listen to most sides, not all sides. Like the record in GEB that destroys the record player itself, our sense of fairness and aversion to hypocrisy can be exploited and destroyed with the right arguments. This happens in the real world, more often over time, and we should recognize it before we’re stuck in endless mental gymnastics trying to break out of political nihilism.
-
-
-
-
Richard Stallman said, regarding an abortion joke in glibc
IIRC he was strongly of the opinion that the joke was not about abortion, but about censorship.
-
I am very positive this is true. Granted, the own Weltanschauung truly reflects in one’s coding style in most cases, however, both pro-life and pro-choice advocates can have e.g. a profound desire for simplicity in their designs regardless of their opinions.
Things like this, in my opinion, are more rooted in self-discipline and habit, which is more or less not correlated with one’s opinion.
-
-
Option #4: Start a product business (the right way)
Did the author ever run a business?
The most realistic chance of working less than 35 hours is slacking off somewhere as a salaried employee.
-
Slacking usually requires you to be in n office, so you’re still working
-
-
-
It depends on the business, though. I know people with couple moderately-successful iOS apps where yes, they do some support nd bugfixing, but can do it on their own schedule and the money comes it “on its own”.
Startups are a particular kind of product company that is high-pace. But small-businesses can also exist.
-
-
He did found a startup in the early 2000s.
-
And it failed! Because we did it the wrong way. But Amy Hoy has done it the right way, and teaches how, which is why I linked to her stuff.
Also note that VC-backed startups are very definitely NOT the way to get decent working hours as a founder. It’s totally possible to work decent hours (<40) as an employee, as I’ve done at last three jobs.
-
-
-
you are, in fact, permitted by the mail RFCs to edit the sender’s message as you please when replying - a style called bottom posting
Nope. Bottom posting is when you treat the sender’s message as immutable and tack on a reply at the bottom.
What the article describes is “inline reply”
Do they owe enough to make legal proceedings worth it? Odds are the court will easily judge in your favour (the other side often doesn’t even bother to show up in such cases IME, they don’t want to pay a lawyer themselves). Then, if you suspect they have some or all of your money, it gives you the legal authority to have the money seized from the accounts, etc (details will vary by jurisdiction)
A team of developers was working with them, that is why it makes it worth it. I am sure they have the money, but probably not enough money to pay debts and to finish the development before a new investor or the IPO goes through.
A team of developers was working with them, that is why it makes it worth it. I am sure they have the money, but probably not enough money to pay debts and to finish the development before a new investor or the IPO goes through.