I love the fact that the author "wrote" this page with massive CSS framework (tailwind) and some sort of Javascript framework, with a bundler and obfuscator - instead of a plain, simple HTML page. Well played! :-)
Fair, the author's point would have been stronger if the page was made using just static HTML/CSS.
But I have to defend Tailwind, it's not a massive CSS framework, it just generates CSS utility classes. Only the utility classes you use end up in the output CSS.
good point, got rid of google font. for the rest, it's just that the DX is unmatched to get something quick and dirty started up. (I _could_ have done a simple .html though).
and I'll concede that react is overkill for this, I just wanted components + typescript to not waste time on silly vanilla js bugs
haha, right?!
I'm totally onboard with the author's philosophy, hence for websites: https://mastrojs.github.io – the simple web framework and site generator you could have built yourself.
This is less an example of why serverless was bad but rather an example where using non-suitable services for tasks they were not meant for.
In this case they were using AWS Step functions that are known to be expensive ($0.025 per 1,000 state transitions) and they wrote:
> Our service performed multiple state transitions for every second of the stream
Secondly, they were using large amounts of S3 requests to temporarily store and download each video frame which became a cost factor.
They had a hammer - and every problem looked like a nail. In my experience this happens to every developer at a certain stage when he/she gets in touch with a new technology; it doesn't mean that the tech itself is bad - it depends on the scenario, though.
Having a good keyboard is important (not only for ergonomics, but also for efficiency) in our business. But I find I'm having difficulty when temporarily switching from US to DE keyboard layout, or when using a mac (vs linux) - so what would using a completely custom keyboard do to my general computer user ability?
This is why I never considered buying one of these...
I find that changing the layout creates significant mental overhead for me as well, so I just don't do it. I use the NEO layout [1] which contains all the characters and symbols I could possibly need in reasonable locations. I barely need to leave the home row to write any of the symbols needed during programming or writing TeX.
As for physically different keyboards, I've found it to be a much lesser issue than I expected. I recently got a Moonlander [2] due to general hand and wrist pain that could only be attributed to strain from typing.
I took care to map the layout quite closely and the physical layout was almost immediately usable. I started at around 2/3 my normal typing speed but was back to 100% in a matter of a week.
Going back to a normal keyboard takes minimal effort. I can still type on them quickly, I just loathe them more than I did before now that I know how much more comfortable it could be.
At least on the mac I do not use the german layout at all. For typing an Umlaut I type instead Opt(Alt) + 'u' to get an ¨-sign, then I type a/o/u to get the letter. The same with ß - just Opt + 's'.
It is maybe a bit annyoing if I have to type in german a lot on some days, but it is less annoying then to keep an extra layout. And since I sometimes have to type in french and often in russian... well, you get the idea, it would be a mess of 4 keyboard layouts. With special characters I can push the amount of keyboard layouts just to colemak and russian.
> Let's say we have it every day at 9:30 and I get stuck at 11:00. Does anyone really expect me to wait almost a whole day to get help, or should I just go talk to someone about it right away like a normal adult would?
The standup would be the safety net when people don't see that they're stuck, know what to do and are afraid to ask / hands down in smth they just don't see the obvious.
Uncovering this in a standup should prevent them from "wasting time" even longer.
I have rarely seen this in my experience so far; either people aren't as dumb as people believe or they know what to report to not fall into this "let me take over here, you seem to have messed up" category.
> either people aren't as dumb as people believe or they know what to report to not fall into this "let me take over here, you seem to have messed up" category.
Exactly. If you're starting to get stuck and you're afraid to ask for help, the last thing you're going to do is making that obvious in front of the whole team and/or your boss. If you didn't believe you can manage it on your own, you'd have asked for help already.
The update mechanism itself is still insecure, as the wordpress instance must have the ability to exchange its own source code - something you'd at least call risky. Web applications should run with the least possible privileges, ie. only with permissions to write to dedicated locations on the filesystem (user uploads), and read permissions for the code.
PHP has composer, a dependency management system. There's an option to build a wordpress project using composer.
Even more, there's even a boilerplate project that you can use to bootstrap your new wordpress setup - see https://roots.io/bedrock/
> Web applications should run with the least possible privileges, ie. only with permissions to write to dedicated locations on the filesystem (user uploads), and read permissions for the code.
This isn't wrong but I'd argue it's a lower priority concern than you believe it is.
A comprehensively secure automatic update system would have process isolation between the normal web interface and the updater (and the latter would run as a different, more privileged user). However, not everyone can do that. (Shared hosting, etc.)
The goal of an automatic update mechanism should be to prevent the rampant exploitation of 1days, like what happened with Drupal not too long ago.
If you had to choose between "owned within 7 hours of the advsisory" or "less theoretically secure in a constrained environment but still securely self-updating" in the CMS/blog threat model, the latter wins.
There's no easy way to rearchitect WordPress to support the principle of least privilege and process isolation for their auto-updater in a way that ensures everyone still uses it. So for the time being, that's worthy of being called out, but isn't a big enough deal to label the whole shebang insecure. Because "insecure in which threat model?"
> A comprehensively secure automatic update system would have process isolation between the normal web interface and the updater (and the latter would run as a different, more privileged user). However, not everyone can do that. (Shared hosting, etc.)
That's right, and I also think the popularity stems from the simplicity and the fact that it existed when the whole blog thing took off.
There's actually the option to provide your FTP credentials in the admin console and have wordpress update itself over an FTP connection. It is process separation, then, but OTOH potentially exposes your webspace credentials to an attacker. :-)
Problem is that there's a ton of shared hosting providers that won't support such a setup, as it would require a lot of modifications to 1-click-installers for WordPress. General WordPress users have no idea about such things, and the demand for more elegant solutions is therefore quite small.
That, and the fact that WordPress popularity stems from the fact that it's fairly easy to set-up without technical know-how, makes it unlikely that another path will be chosen in the close future.
Can you elaborate on the specific threats you're thinking of?
I'm picturing a WordPress environment where all the source code owned by root with R+X permissions for www-data and nobody else, and an "Uploads" directory owned by root that has R+W for www-data with no X.
So assuming we have locked down permissions but still running a vulnerable plugin; we still have code execution and can ex-filtrate secrets via Uploads or create symlinks or upload malicious payloads. We just can't use the webserver to change code. You could still steal credentials that give us access via other means.
By being able to modify executable files on the webserver, an attacker can add a backdoor through a security hole quite easily. Without, he could just make use of the security hole as of itself.
I am a (happy) user of homeshick (https://github.com/andsens/homeshick), but this project really seems to top it by providing the only feature that I've missed until now:
- use the same source file with different results for different machines (eg. .gitconfig for home and office machines)
- option to store secrets in a credentials database and extract them from there (because you wouldn't want to store them in a git repo - even if it's a private one)
Homeshick is indeed great, been using it for years. Every time I've compared it to other solutions, it always comes out on top feature-wise. The other solutions are always missing something, like tracking either files and/or entire directories. Tracking whole directories is very important for e.g. storing an entire ~/.emacs.d in git, and tracking individual files is nice so I can just `homeshick track main ~/.config/some-config-file` without tracking all of ~/.config.
> - use the same source file with different results for different machines (eg. .gitconfig for home and office machines)
I do that by storing each machine's copy with its hostname as a suffix and symlinking it into place on each machine. e.g. ~/.config/anacrontab.systemA gets symlinked to ~/.config/anacrontab on systemA, and the repo contains both ~/.config/anacrontab.systemA and ~/.config/anacrontab.systemB. I can even modify one machine's file from the other machine, and it will be updated on the next push/pull.
But having integrated support for this would be nice.
If it wasn't dangerous one could try the same with hydrogen. If the post is correct it should have a similar effect (if the device doesn't explode during the test).
Basically electronic oscillators rely on a very small piece of quartz crystal that is cut in just the right shape. Quartz has a phenomena called piezoelectricity, where if you apply an electric field, it deflects slightly. Conversely, if you deflect it, it creates a small electric potential. A properly shaped quartz, when exposed to some circuitry (oscillator circuitry; positive feedback), it will resonant at its natural frequency, not unlike how a tuning fork resonates at its natural frequency.
Since the crystal is literally vibrating inside the metal can it's packaged in, the atmosphere around the crystal influences the natural frequency. Helium will make it vibrate it faster, since it presents less air resistance to the crystal.
Note, however, that MEMS oscillators (which modern iPhones use) and quartz oscillators are not the same thing. SiTime's MEMS oscillator is made of silicon, not quartz.
"Any clues why such an environment doesn't make Android phones behave in such a way?"
A bit of googling seems to indicate most smart phones have a crystal oscillator. But, Android would have the advantage of manufacturer diversity...so lots of different types of crystal oscillators, perhaps some that are sealed better than the iphone ones, or quartz vs silicon, etc.
This does sort of illustrate an issue with the iphone tech monoculture. Lots of devices with similar components, and similar versions of software. Find something that adversely affects them, and you can disrupt a lot of people. It's probably hard to find something similar for Android since the hardware and even software varies a lot.
Most crystals have better sealing :-). SiTime explicitly(-ish) acknowledges that their older-generation packaging was less efficient on their website:
"How effective is the hermetic seal of MEMS oscillators??
One of the key elements enabling extremely stable MEMS resonators is SiTime’s EpiSeal™ process which hermetically seals the resonators during wafer processing, eliminating any need for hermetically sealed ceramic packaging. SiTime’s EpiSeal resonator is impervious to the highest concentration elements in the atmosphere, nitrogen and oxygen, and therefore acts as a perfect seal. Previous generations of EpiSeal resonators may have been impacted by large concentrations of small-molecule gas. Newer EpiSeal resonators are impervious to all small-molecule gases. Please contact SiTime in case you are planning to use a SiTime device in large concentrations of small-molecule gas, so that we can recommend an appropriate, immune part."
Apple uses these oscillators. They are substantially more expensive than crystal oscillators, but are much smaller and use less power. This may explain why the Android phones, which are more price sensitive, didn't use them. It does seem that the current generation of SiTime oscillators don't have a problem with Helium, so perhaps current generation iPhones don't either.
This is an unsolved problem; some people work around it by managing multiple twitter accounts, one for each "channel". It doesn't scale by topics, though.
OTOH if I have to think about which channel / user I tweet to, I think people would tweet less. A bit of noise is ok, I guess.
