diff --git a/src/drafts/XXXX-roe-colorschemes/index.org b/src/drafts/XXXX-roe-colorschemes/index.org index 04fa819..acec92d 100644 --- a/src/drafts/XXXX-roe-colorschemes/index.org +++ b/src/drafts/XXXX-roe-colorschemes/index.org @@ -1,9 +1,16 @@ -#+title: My story about colorscheme -#+date: [2020-05-03 Sun] +#+title: Return of experience about colorscheme +#+date: [2020-05-04 Mon] #+author: Yann Esposito #+EMAIL: yann@esposito.host #+KEYWORDS: colorscheme -#+DESCRIPTION: A generalization of solarized (https://solaryzed.esy.fun). -#+DESCRIPTION: I tried to make keep the same fundamentals and to free some variables. -#+OPTIONS: auto-id:t toc:t +#+DESCRIPTION: The list of colorschemes I used, why I changed. +#+OPTIONS: auto-id:t toc:nil #+STARTUP: overview + +* Local variables :noexport: +:PROPERTIES: +:CUSTOM_ID: local-variables +:END: +# local variables: +# org-download-image-dir "./img" +# end: diff --git a/src/drafts/XXXX-roe-colorschemes/mo5.jpeg b/src/drafts/XXXX-roe-colorschemes/mo5.jpeg new file mode 100644 index 0000000..5092f5b Binary files /dev/null and b/src/drafts/XXXX-roe-colorschemes/mo5.jpeg differ diff --git a/src/drafts/XXXX-who-control/index.org b/src/drafts/XXXX-who-control/index.org new file mode 100644 index 0000000..99a04c5 --- /dev/null +++ b/src/drafts/XXXX-who-control/index.org @@ -0,0 +1,233 @@ +#+Title: Who is in Control +#+Subtitle: How I started to take care of the tools I use. +#+Author: Yann Esposito +#+Email: yann@esposito.host +#+Date: [2019-08-17 Sat 20:00] +#+KEYWORDS: opinion +#+DESCRIPTION: Modern tools disapears +#+DESCRIPTION: I include applications, web applications, websites, editors, programming languages. +#+LANGUAGE: en +#+LANG: en +#+OPTIONS: H:5 auto-id:t +#+STARTUP: showeverything + +#+begin_notes +This post is a reaction about a few articles I read in a short amount of time. +So do not take that too seriously. +But it will certainly. +#+end_notes + +I had to work a lot this week and I mostly didn't read any news. +This morning, I started to read the article I missed. +Here are the articles and threads I read: + +- [[https://news.ycombinator.com/item?id=23102430][Zoom acquires keybase]] +- [[https://news.ycombinator.com/item?id=23107123][Making Emacs popular again]] +- [[https://news.ycombinator.com/item?id=23092904][Github Codespace]] + +I don't think I read those in that order. + +A few years back, HN comments made me look at Clojure. +That was also many positive HN return of experience that made me confident +to use it for a serious business work. +Lot of great advices regarding every aspect of the life and software programming. +Project architecture, etc... +Most of the time, article were good, but HN comment were really great. +Of course, even after a few years, people started to explain that HN +quality dropped. +This can totally be an observer bias. +HN quality might not have really droped but the reader has changed. + +So I get it. +I changed a lot accross those years. +And also, yes, HN is mostly see by startupers. +So this is also another big bias. + +Still, I'm sad to see that the most popular opinions expressed in those +discussion threads have diverged so much from my point of view. + +When I see those news I see a common pattern. + +One big corp kill a product that should exist for the common good. +And of course, each time this is because having a common product is +incredibly hard. +Most "common good" products do not have what it takes to be sustainable +enough. +Either you create a very big open-source ness of developers that give their +work freely, or you can grab enough money from different source so you can +pay a few of them. + +And this is why the startup model is a lot more efficient. +You want a great product, buy the best best people. +For that you need money and passion. + +Most /Free Software/[fn:1] must deal with community driven development. +They should often find a concenssus. +They generally don't have money to pay the people working on that product. +While startup looking to create popular product must take a lot of care +about UX and UI. +What that mean is that the product should need the least possible amount of +energy and learning from the users. +And this is a great thing. +The problem with this approach is that most of the time it also forces +users to follow the workflow and limitations imposed to make it easy to use. + +And sometime worse, product simply disapears or change so much I simply +didn't want to use them anymore. + +So here is a non-exhaustive list of ~/.*ware/~ that, as a user you don't +want to deal with: + +- /bloatware/: remember digg, readitlater, stumbleupon? +- /downgradeware/: Swagger-UI v3 (v2 is neat), reddit new redesign (looks better, but slow) +- /payware/: You rely on our feature, but now, we want you to move or to pay. Fair ;) +- /crapware/: Nothing works as expected unless you pay: Twitter streaming API? +- /dieware/: Remember Friendfeed? Google Reader™? +- etc... + +Regarding the integration of VSCode™ inside GitHub™ I think this is even worse. +This is what I would call a /trapware/. + +#+begin_notes +/trapware/: +A software that is intented to put you inside a closed ecosystem. +By slowly but surely add features that while looking great for the user at +first sight will ensure to entrave other tools to interoperate. +#+end_notes + +Furthermore, the fact that Microsoft is involved really give this situation a taste of [[https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish][EEE]]. + +So what is the real concern for me. +I imagine a new working environment where surveillance and control on the +developer is a rule. + +For a startup CTO/CEO this GitHub™ full work environment offers the +following advantages: + +- /security/: impossible or very hard to steal the code by a single dev. +- /homogeneity/: all dev must use the same development environment. Thus + the integration of new dev is faster. +- /cheaper/: don't need to pay for a full featured, fast machine to each new developer. + A simple machine able to display an electron app will do the trick. +- /stats/: you can observe the throughput of your developers. How many + commits a day, how many lines of code, etc... + How much bugs involved which part of the code and thus which dev to blame? + How much time the dev is typing, moving its mouse, how much copy/paste is + involved, etc... + +For the single developers and open source developers this offer: + +- /homogeneity/: if I learn how to work in this environment, I'll be easier + to recruit and I'll know how to work fast. +- /lower barrier to entry/: for an opensource repository, it will become much + easier for anyone to propose a PR to fix some issue. No need to local + clone the project, no need to download all the dependencies to test it + locally, etc... + +But the price to pay is hidden. + +1. First, you are now, not able to choose your local working environment on your machine. +2. GitHub™ can still change so much to become one of the previously mentionned ~/.*ware/~ you + don't want to be involved with. + Like forces you to pay a lot more, remove features, start to become a + bloatware, make it harder to interop with other platforms (prefer Azure + to AWS etc...). +3. If everything involve machines in the cloud via the browser, + it makes it harder to play locally with your machine. +4. Sureveillance on meaningless or wrong metrics about your work. + Instead of being evaluated on the feature you shipped or on other higher + level metrics. It will be very tempting for your bosses to find flaws in + your working habits. + We are already living in a world were surveillance, metrics and stats + are too easy to grab about a person. And anyone involved know this is + all bullshit. + Human are very good to play those kind of games. + So people really working hard for the best will certainly perform badly + compared to other people that simply trick the system. + +So if the endgoal of GitHub™ is really to help open source and single +developer. +And more generally provide simply a better working experience by adding a +new tool without any hidden marketing plan. +Yes great. But I really doubt a company offer anything without a plan to +make it worth it. + +Until here I mostly talked about the Github Codespace article and HN thread reaction. +Where I saw a lot too much enthusiasm about this news for my taste. + +But the other articles and their reaction in HN show that yes, HN might not +be for me anymore. +Most of the top level comment in [[https://news.ycombinator.com/item?id=23092657][Name one idea that changed your life]] +are about how to not fall for the trap of the [[https://nesslabs.com/confirmation-bias][confirmation bias]]. +That's really great. +But as a former scientist, this is only the very first step. +I might be totally wrong. +But I would have expected that the same question being answered a few years +back on HN would have also provided those answers but also deeper ones. + +The [[https://news.ycombinator.com/item?id=23102430][Zoom acquires keybase]] is just again a confirmation that, yes. +When you chose to adopt a tool. +You should ask yourself if it is worth to invest your time and energy in it. +Because most of the time, the tool has a finite and short lifetime. + +Finally, about [[https://news.ycombinator.com/item?id=23107123][Making Emacs popular again]]. +The first comment was about how VSCode is easy to start with as compared to +Emacs that need a lot more time to configure correctly for your needs. +Yes, VSCode certainly just work and is easy to use. +But Emacs is another beast. +VSCode can become bad very fast, you don't control how it will evolve. +Emacs on the other hand is 44 year old and was designed so that it adapts to you. +You are the one using libs and customizing. + +It's a bit of the same Frameworks vs Libraries argument. +Framework are easier to start with, but soon you find corner cases were you +cannot use them correctly and are fighting agains the framework. + +A Library on the other hand, is just a bunch of helpers you can use. +And if you need another functionality, just make it using the libraries. + +So libraries, programming languages and tools have generally subject to the +same debate. +- Easy now, but more difficult later VS harder now but easier in the future. + +So if you are going to need a "solution" for a problem for a very small +amount of time. The "Framework/3rd party tool/etc..." is certainly the best +solution to choose. +If you're going to make a living with it, and pass most of your time with +this tool. I highly suggest the second option. + +Emacs is like that. +Hard to start, but with emacs come a huge power that you will probably +never be able to get with any other IDE/Editor. +And above this, choosing a Free Software gives you a lot more control about +its evolution. + +I wouldn't be surprised if in a few years VSCode started to show ads during +startup ad why not in the middle of your work. +On the other hand this will never occurs within Emacs unless you are doing +this to yourself :). + +[fn:1] note I said /free software/ and not /open source/; c.f [[https://www.gnu.org/philosophy/open-source-misses-the-point.en.html][Why Open Source misses the point of Free Software]] + +* Conclusion +:PROPERTIES: +:CUSTOM_ID: conclusion +:END: + +Choosing a tool: + +- will I use it a lot? +- do I trust that I'll use the same tool in 5 years, 10 years? +- who is in control? +- Is it worth to invest my time in it? + +Most of these new tools from startup disapears after about 5 years. +So if you plan on using a tool for something important for you. +Take care that it will exists as it is today, or even better in a few years. + +* PLAN :noexport: +:PROPERTIES: +:CUSTOM_ID: plan +:END: +- common point, modern tools deprecates and disapear. +- how to chose a good tool