The second one is (more) interesting, IMHO. The entries on how most of the keys have some defect or other are worth reading, since mostly nobody is looking at this stuff.
The relevant paragraph on Feitian:
Feitian ePass
ASN.1 DER is designed to be a “distinguished” encoding, i.e. there should be a unique serialisation for a given value and all other representations are invalid. As such, numbers are supposed to be encoded minimally, with no leading zeros (unless necessary to make a number positive). Feitian doesn't get that right with this security key: numbers that start with 9 leading zero bits have an invalid zero byte at the beginning. Presumably, numbers starting with 17 zero bits have two invalid zero bytes at the beginning and so on, but I wasn't able to press the button enough times to get such an example. Thus something like one in 256 signatures produced by this security key are invalid.
Also, the final eight bytes of the key handle seem to be superfluous: you can change them to whatever value you like and the security key doesn't care. That is not immediately a problem, but it does beg the question: if they're not being used, what are they?
Lastly, the padding data in USB packets isn't zeroed. However, it's obviously just the previous contents of the transmit buffer, so there's nothing sensitive getting leaked.
The article doesn't make it clear - but "elsewhere" seems like it would clearly be better than urban busses. They assert that even in areas where grid electricity to charge the busses comes entirely from fossil fuels, there is less pollution produced - presumably because it is somewhat easier to make a fossil fuel plant cleaner at scale than 100s of busses. Fossil fuel plants could be any of natural gas (very clean), coal or.. oil, which in this case is something resembling diesel, or the diesel constituents of crude.
The title is (of course) fairly misleading - while we've got electric boats and semis it is unlikely that long haul transport for either will be electric any time soon. But - at least they are away from urban areas, for the most part.
You can essentialy use the batteries of electric vehicles as energy storage. Most passenger vehicles don't need to run at noon when everybody is at work and surplus solar is available. They don't need to run at night when people sleep, electricity demand is low and wind whirls. Buses can also be scheduled for loading during these periods as they can run 200 km on a charge and transport capacity is adjusted according to demand - only a fraction of the fleet operates during low demand periods mentioned above, the rest can sit and charge. Long haul transport can run on plug in hybrids using HCCI internal combustion engines and/or gas turbines powered by diesel/gasoline or ideally DME/LPG. This can be all tuned using economics. Coal needs miners for extraction and is dirty to burn. Gen III+ and IV nuclear and geothermal are much cleaner and safer alternatives for base load.
Hugo is nifty. It is in Golang. It is wicked fast.
But.
Like most of the static site generators out there, it is so hyper-focussed on some aspects that it stumbles or completely misses others. I believe that Hugo (and others) take Markdown in precisely their expected format, and layout, with their format of header and, with precisely the correct version of config file and template.. turn it into some really nice looking HTML. Fast.
I guess - even after 5 years they aren't attempting to call it 1.0 at least. Maybe the other things will get fixed before then.
You might even be able to take your existing Markdown stuff and convert it - but be prepared to fiddle with Markdown syntax a bit, and headers, and file layout, etc.. potentially for hours. And hours and hours. And hours and hours. Not so fast any more, is it? Hugo is not alone here.
The number of themes available is amazing! And they look fantastic! But - you're going to have to spend many more hours digging to find one that puts the blog on a separate page, instead of front and center.. because 80%+ of them are oriented towards blogs only.
Now.. a week later... new minor release time. Does the new release work with your existing config? With your existing theme?
Oops - you waited a month and missed a few minor releases.. will everything break now? How do you ensure that your theme keeps up to date with your release? Git hooks, git submodules? What fun! How.. fast? Not if you're futzing with all this stuff.
Hugo isn't alone here - Jekyll, Pelican to name two I've tried also have problems to a greater or lesser degree.
Software should be judged based on how useful it is. Hugo isn't what you or I would build, but a lot of people find it incredibly useful. Same as WordPress, where their slogan "code is poetry" makes me think "yeah, vogon poetry".
Well, to be fair, the problems you've pointed out are quick fixes.
Hugo works fine out-of-the-box with markdown files that don't have any headers. You'll just be seeing some reference errors for things like Title, probably.
And moving the blog to a separate page wouldn't take hours. The homepage comes from `layouts/index.html` [0], and each type of page already has a list page ( `page_type/_index.md` ).
Not sure if it'd really take that much longer to get your head around how Hugo works versus a traditional CMS. At least with a static-site generator, if you keep it outdated (and therefore don't need to bother with any breaking changes), any unfixed vulnerabilities aren't facing the web.
I just switched my personal site from a custom Python script that generated markup to Hugo...plus custom Python scripts.
I wanted to automate the upload process too so I made something that is somewhat but not quite rsync-like (it uses a date and size heuristic to do fast incremental updates) - and then for the site content I realized that Hugo's design was resistant to text + image bundling, favoring static data independent of markup. The documentation on making a bundle work from within Hugo was both extremely limited and actually broken on current versions.
So I just rolled another script to publish content with. All it does is pre-process the Markdown and copy files.
Still, by going this route I'm still gaining advantages over the old system. It's nice to have a system that takes care of common stuff - themes, list generation, final markup. But it's much more valuable when it's supplemented with a custom system that lets me author the content at the level of abstraction I need.
I switched from Octopress to Hugo and it couldn't have been more painless or pleasant. This was still early days for Hugo, I ran into a bug, posted a ticket and had it fixed in a few hours.
Upgrading from one version to another has been painless as well so far.
Did you read the blog post at all? It's a little bit ridiculous how many of the things you mention here were also mentioned there.
You:
> I believe that Hugo (and others) take Markdown in precisely their expected format, and layout, with their format of header and, with precisely the correct version of config file and template.. turn it into some really nice looking HTML. Fast.
The post:
> Currently, in addition to Hugo’s list pages, every URL must be backed by a content file (Markdown, HTML etc.). This covers most use cases, but we need a flexible way to generate pages from other data sources. Think product catalogues and similar.
You:
> I guess - even after 5 years they aren't attempting to call it 1.0 at least. Maybe the other things will get fixed before then.
The post:
> Hugo has stuck with the sub-zero versions to signal active development ... But we are closing in on the first major stable version.
You:
> Now.. a week later... new minor release time. Does the new release work with your existing config? With your existing theme?
The post:
> with a new main release every 5-6 weeks. But we take stability very seriously (breaking things add lots of support work, we don’t like that) and most site upgrades are smooth.
Words in a blog post are easy to write, the proof is in the actual use of the software. But equally, to me this post strikes a positive tone about the future of Hugo as more than just a tool that helps you ditch WordPress. A lot of that work will have already started and I'm sure they would welcome your contributions, large or small.
Hello kqr! I didn't expect Org mode to be mentioned in this Hugo thread. So I'd like to mention my ox-hugo[1] project here. Here are few real-world examples of people using ox-hugo + Hugo: https://ox-hugo.scripter.co/doc/examples/ (while on that page, also search for "Exported from" :)).
ox-hugo basically lets each tool to do what they are best at: Org mode deals with the rich markup and Emacs/Elisp processing, and Hugo deals with the super-fast Markdown->HTML conversion.
[1] ox-hugo is an Emacs package that exports from Org mode to Markdown format that's compatible with Hugo/Blackfriday + automagically converts natural Org metadata to TOML/YAML front-matter.
I love org-mode, but the export is a mess. It produces sloppy HTML and garbage CSS, what I want is semantic HTML5 and custom CSS. Actually, I should probably just spend the time to build what I want and contribute it back to the org project.
I actually have it customized to put some CSS in, but it is suboptimal.
Can you expand on that a bit? Can Hugo not take other formats?
I use Pelican. It supports markdown and rst out of the box. It's fairly easy to write a plugin to support another format. So I wrote one that takes in Org files (I think it just uses pandoc behind the scenes to convert to rst). Writing posts is much better now that I can author them in Org mode.
So if someone wants to author in Org mode, but not use the clunky Org exporters, consider using a static site generator that allows you to have a custom input format.
Not to be a wise ass, but because I'm genuinely curious: who cares how fast it is? How often are you regenerating pages? Or is it a factor because of the change-make-check-change-again cycle?
It matters if it takes more than a short while to post your stuff. Jekyll/Octopress would take 20 minutes or so to regenerate my not all that large blog, I imagine that with 1000's of pages it would be unworkably slow.
I've tried Jekyll on multiple occasions and have always been put off by just how huge the tool is.
I just want to turn my markdown into pretty HTML. That's all. Jekyll feels like this giant sledgehammer that's built to hit a tiny nail... and doesn't even hit the tiny nail correctly every time.
In my case, when I wrote a plugin for Jekyll, I felt mildly upset about all Ruby things I needed to install and to some degree understand. I felt Jekyll was too complicated and complex. — Maybe if one is used to the Ruby world already, one won't feel in that way.
I'd like to point out to those fluffing about the price for fastmail - Google Apps For Business (aka: pay-for-gmail) runs $5/person/month, minimum. It does have additional services (eg: the office-apps), but AFAIK, even the business one doesn't promise that it won't look through your private info. Fastmail does make this promise.
There is certainly no way you can run your own email server for $50/yr (or even a few hundred per year), even if the hardware itself were free, and you were not counting the cost of the internet service (eg: using your own home internet), and you were willing to accept that you might fail to update some things, sometimes, etc. If you value your time at all. Even at say, minimum wage.
Not to mention the deliverability issues etc.
If you just love doing it, then, by all means, do it. Just don't imagine it is somehow less than $50/yr, or comparable in quality.
I do wish Fastmail had more competition, even if it cost a bit more, and (as the Fastmail folks here have said) the competition participated in open standards and contributed to open source. I think others are "in the works" particularly with (even more) security/privacy emphasis. But, IMHO, eg: protonmail does not currently directly compete. We'll see what pans out.
> There is certainly no way you can run your own email server for $50/yr (or even a few hundred per year)
If you're talking about self-hosting at home, then probably true unless you're using something like a Raspberry Pi to run the server.
You can get web hosting including email at your own domain for somewhere around $50/year, though. I think I'm paying $26/year for hosting and $13/year for domain registration (or thereabouts, it's a trivial amount anyway) which comes with as many email addresses as I want at the domain, 10GB storage, and some amount of web traffic (50GB/mo maybe?) that's never been an issue.
Firefox is indeed, much faster and less memory intensive than it used to be. I started using it heavily (again) roughly when Quantum came out after giving up on it for years as unusable. (like many, I think - hence the article).
However.
I still find it very crash-prone. Less so over time, since Quantum came out, but still.. very crash-prone.
Perhaps I use it differently from others?
I use different Profiles to separate concerns (and give myself some small modicum of cross-concern privacy - if nothing else auth cookies are reliably separated). At any given time, I have up to 5 separate Profiles running.
With Firefox, each Profile is a fully separate PID (I assume their newer Containers are not), and there are affiliated PIDs for "Firefox CP Web Content" (similar to Google Chrome Helper, I assume).
On any given day when I log into my system in the am, one or more of those Profiles has crashed, all affiliated PIDs are dead and the Crash Reporter is up.
I don't believe anything I'm doing in any of the Firefox Profiles is particularly unusual, or extreme. No social networking, or anything with infinity-scroll. No video streaming (eg: Youtube).
So Mozilla - what gives?
Despite that complaint, I still happily use it because I believe Mozilla is much more interested in my privacy, and much more dedicated to FOSS, and because I mistrust Google. Thanks Mozilla!
I meant to add - Chrome has maybe crashed on me a couple of times in that same year (versus one or more crashes per day from FF!), despite arguably much much heavier use, including all of my Youtube, social networking with infinity scroll etc.
Too engaging is part of the problem, of course. A public park or beach might arguably less engaging than the commercially driven next season of that show on Netflix. Doesn't mean that there shouldn't be thriving parks/beachs.
Or.. that there cannot be thriving parks and beachs. There provably are. There are also lousy ones overrun with trash that no one likes or uses.
So the issue would seem to be - how best do we make the open source, public funded options more like the parks and beaches that everyone uses, and less like the ones that people hate...without a profit motive.
Okay, don't ask customers, but do think about it a bit. They don't want yet another smartphone, physically embedded in their car running crappy, insecure, counterintuitive, out of date software.
They've already got a smartphone. They already know how to use it's UI. Did you know people drive different cars sometimes?
They don't want or need to be able to order Dunkin Donuts from the crappy, insecure, out of date smartphone welded to their dashboard. If they want Dunkin Donuts, they'll order them from the smartphone they already have. Glueing it into the dashboard doesn't make it any safer to operate underway, and if they've got to stop anyway - they'll use their smartphone. And it isn't going to make you many dollars off those Dunkin Donuts referrals.
It seems they would like a way to hook up the smartphone they already have to the car speakers, and possibly even a microphone, built-in somewhere near the driver. Ideally multiple ways, since phone makers keep changing the game.
Maybe add some physical tactile control buttons, for volume for example. Maybe that attached device needs to be controlled. You might be tempted to put a touchscreen in there. Don't.
They've already got a touchscreen, which is unsafe to use while driving. Give them more knobs and buttons they can use by feel. If you don't give them another touchscreen.. they won't use what you didn't give them.
If you must put in a screen, make DAMN sure that the software (and hardware!) behind it is as relevant as you think you can manage for the expected lifetime of the car. Like 10 years. How about 20 years? This might seem like an opportunity for planned obsolescence - it isn't. Just do it well, and do it right.
If it absolutely must be more than just an audio+mic jack and some buttons then:
* make it as secure as you can make it, and can be updated, securely (thumb drives with checksums are good, wireless, not so much).
* it is as bug-free as you can make it, and has the fewest possible features you can get away with - on the assumption that your customers will always have a <= 18 month old smartphone in their hands
Sure - we can rip out the crap from the factory, and we will, but that is just more waste. Please do it right and maybe save us all some hassle.
The great thing about corporate missions & goals is that they are written so broadly:
"Our goal when we created Tesla a decade ago was the same as it is today: to accelerate the advent of sustainable transport by bringing compelling mass market electric cars to market as soon as possible. " (https://www.tesla.com/blog/mission-tesla).
Thanks to Tesla - seriously(!! COULD not and WOULD not have happened without them), we now have a compelling mass market electric car on the market.
Well no, companies have been trying on EV every decade since the invention of the car.
The Prius normalizing an electric drive train pushed full electric further into the mainstream then Tesla has. Granted Tesla's investment into batteries bumped Panasonics time line up a bit and bumped full BEV up a bit but a compelling mass market electric car on the market has been clearly inevitable since 2000.
Edit: I changed it from "Tesla ... may have". To "Granted Tesla " to more accurately reflect my evaluation of Tesla's contribution to the time line.
Fair enough - I did fail to give Toyota credit, where credit is definitely due.
But I would say it is more a case of "necessary, but not sufficient."
Toyota unarguably pushed electric into the unsexy, mass production, mass consumption mainstream. This was a necessary step.
But Tesla showed that electric COULD be luxury, performance, etc - not necessary for mass market - but the related headlines generated arguably were.
But also that _pure electric_ could be delivered with _more than enough_ range to eliminate range anxiety, even with "notably better than a Prius" levels of performance. And it could at least appear to be "mass manufactured" (even if, on Toyota/Chevy/Nissan scale, or if you will, BMW/Mercedes/Lexus/etc they really weren't). This WAS necessary, and did cause a tipping point that, IMHO led to the Chevy Bolt.
The Prius led to the Bolt evolutionarily.
The Model 3 led to the Bolt "by Marketing force."
And now we have a Bolt.. and basically no Model 3.
We'll see what happens in the next couple of years.
You jest, but knowing Musk, he'd consider that a win.
The point of Tesla under his lead was always to make transportation electric ASAP; not necessarily for Tesla to be the biggest player forever. I.e. Tesla is means to an end, not an end itself.
In any case I'm not sure I'd give credit to Tesla on that. The Bolt seems more like a response to the Leaf and friends than it is to anything like a Model S.
Maybe. Without a broad consensus from all the involved individuals at Chevy, we'll never know. Were they looking more at the (first edition at the time?) Leaf or the hypothetical and probably unnamed at the time "Tesla mass market model with X miles range and $Y price tag?"
If they were aiming for the Leaf, it appears they got to market faster and better (specs) than the 2018 Leaf. A little surprising from Chevy (when compared to Nissan), particularly since they didn't really have a first edition to build on themselves.
If they were aiming for the Model 3 - they got to market faster and "at least in the ballpark" spec-wise, AND at much much higher volumes than Tesla. To me this is less surprising. A mass-market car producer could get to market with a high-volume car faster than Tesla? And in higher volumes? That isn't so surprising. It would have surprised me _even less_ if Toyota had done it, though they clearly weren't trying. It does surprise me a little that Nissan hasn't, though it is fairly clear that they aren't trying _hard_.
https://pwnaccelerator.github.io/2018/webusb-yubico-disclosu...
https://www.imperialviolet.org/2017/10/08/securitykeytest.ht...
The second one is (more) interesting, IMHO. The entries on how most of the keys have some defect or other are worth reading, since mostly nobody is looking at this stuff.
The relevant paragraph on Feitian:
Feitian ePass
ASN.1 DER is designed to be a “distinguished” encoding, i.e. there should be a unique serialisation for a given value and all other representations are invalid. As such, numbers are supposed to be encoded minimally, with no leading zeros (unless necessary to make a number positive). Feitian doesn't get that right with this security key: numbers that start with 9 leading zero bits have an invalid zero byte at the beginning. Presumably, numbers starting with 17 zero bits have two invalid zero bytes at the beginning and so on, but I wasn't able to press the button enough times to get such an example. Thus something like one in 256 signatures produced by this security key are invalid.
Also, the final eight bytes of the key handle seem to be superfluous: you can change them to whatever value you like and the security key doesn't care. That is not immediately a problem, but it does beg the question: if they're not being used, what are they?
Lastly, the padding data in USB packets isn't zeroed. However, it's obviously just the previous contents of the transmit buffer, so there's nothing sensitive getting leaked.