Not only do companies doing the interviewing need to change the process, I think developers looking for jobs should start refusing to go through the whole whiteboard trivia nonsense. If that reached critical mass, companies would change their interview process real quick.
How many job seekers really want to reject an opportunity over something annoying? When the bills are due and you need health insurance, that’s a rather bold move.
I could only see people with big amounts of savings doing this, and it’d only matter if they were obviously qualified. Otherwise, the recruiting team would shrug and move on, and the job seeker is left wondering if they made a huge mistake. There’s an obvious power dynamic here that can’t be ignored.
That might be true if you’re unemployed and short on options, but often I find people interviewing are already employed and looking to make a change. So for them, saying no just means staying at $CURRENT_JOB a bit longer.
Correct. The solution is to not let yourself get into a situation in which you are unemployed and looking for a job. That is shifting the power dynamic in your favor.
So do you folks tend to keep accounts on multiple instances, or use one instance and ‘remote’ around to chat with others?
I just have one account & remote-follow a bunch of people. I find the remote aspect transparent enough that I never really think about it, actually.
Personally, I set up a few accounts and settled on an instance with a bunch of interesting users and a theme I liked. It was witches.town. Remote follows work pretty well. I don’t think that’d be an issue with most instances.
I would like to see more apps/api level support for one user with multiple accounts, since there are instances I really liked but not as much as witches.town. It does let you import/export account data as a CSV if you want to move or your instance shuts down, though.
I use compatible protocols on my website and aggregator, and interact without an account at all :)
[Comment removed by author]
i quite enjoy it. i don’t know if she has an issue with capital letters, but i don’t really like them.
I think HDMI suffers this problem, too. It carries so many different flavors of types of signals, consumers may assume a device has certain features just because it has HDMI and that’s the cable that carries that feature. Like, does this Blu-ray player support 3d and Ultra HD? As the ultra HD tv takes an HDMI cable, why not?
There’s not really a reason to think cable defines functionality, especially as cables turn into big pipes for different digital codecs and power schemes. And the flipside is that you can just have extra cables in one type for when you need to plug in a device, even if that device is doing something really different. But that’s not the world consumers are trained for, and at a certain point, devices exist to satisfy expectations.
This article leans rather heavily on the assumption cardholders will understand the nature of a private key after just copying a string of numbers for all kinds of forms. I suspect a layperson would try to put both numbers on, or use their private key as their public key. And I don’t think it’s fair to expect every browser to have safe JavaScript crypto to handle the key. What if there’s a malicious extension? Or JavaScript is turned off? Or the browser is really old or they don’t have a computer, as sometimes happens in a country of 300 million plus.
It seems a card with a chip or the printed private key in a less prominent spot with warnings would be better.
The broad idea is appealing, but upgrades of this scale have so many edge cases. And those edgecases are usually really vulnerable people.
Interesting, I’ll give it a go. I know for a fact that people are going to gun it down because it’s electron though.
I mean… it’s a web browser running in a web browser. We’re in, “Yo dawg, I heard you like Chrome tabs, so I put a Chrome tab in your Chrome tab so you can consume memory while you consume memory.”
Fun fact, Servo is currently also like this, the official servo binary only renders one single page, and the GUI is implemented as browser.html. But someone already made a Cocoa based GUI :D
This is interesting. I’ve been wondering what would happen if a browser were better integrated with the operating system rather than being standalone monoliths. Personally, I don’t like the apps-in-browsers model and would prefer to see services heading back to standalone apps with the browser used mostly for browsing. It would be nice to have things like passwords, messenger accounts, etc. be handled by the operating system. The OS could handle logging into things, and then you could just fire up a single browser window to look up URLs and webpages as needed. Having a lightweight renderer that focuses on quickly rendering a single page would be great for this.
That was kind of the dream of Nautilus, wasn’t it? But if electron seems sluggish today, you can imagine how well this played out in 2001.
The dream of the browser for the web and files was realized by Windows 98. Turns out it wasn’t a great idea after all.
I guess the alternative is stripping down the Chromium or Firefox’s source, or write an interface around either of their engines. If you think of it as Chromium with rebuilt UI, I guess Electron makes a little sense as it’s already done the stripping and documenting/exposing how to build on what’s left.
Do you have any benchmarks for
It uses less battery power, so you don’t have to worry about finding a charger.
I’ve found the exact opposite to be true for most electron apps, so I’d be interested to know if there’s something special that you did to preserve battery.
I wonder if it’s leaning on the comparison to a Chrome browser with no adblocking. Ad scripts can certainly use some battery. I really wish there were some benchmarks or something to back this up. Even just a few tests on the dev’s machine.
Okay, the LAST thing we need in laptops is a fscking baseband. Management Engine has nothing on this. Hopefully there will be models without cellular connectivity that don’t have it enabled.
Also, Secure Boot on these laptops is an interesting question. Many people on HN referenced the old Microsoft page that says “ARM devices must be locked”, which was about Windows RT and phones. For this new stuff, we literally don’t know yet…
Laptops with cell connectivity is hardly a new feature. Those have been for sale for at least a decade. Given that I’m data-only on my cell connectivity already, I might find such a feature useful these days…
Laptops usually had discrete modems, not integrated into an SoC like on mobile devices, always-on with full access to system memory.
I’m not too familiar with the way SoC systems are programmed/designed. So, is the software responsible for cellular communication using the same memory as the operating system? And that, presumably, is a binary blob from the manufacturer or cell phone company? And sleep mode would now have some background data using that code?
While a discrete modem would just talk over some bus, only when the system is not in sleep?
It’s a binary blob running on the baseband processor, which might have unrestricted direct memory access to the main processor’s memory. (Even if it doesn’t have that access, it’s still pretty dangerous.)
Yes, a traditional laptop modem would talk over PCIe/USB/PCMCIA/…, only when not in sleep, and the OS would be fully in control. In modern laptops, this is usually a mini PCIe card. Even though PCIe is not designed for hostile devices, IIRC the OS sets up DMA regions and the DMA controller does not allow the device to write outside them. What does the proprietary bus inside of a mobile SoC allow? We don’t know.
On the contrary, I’m absolutely stoked out of my mind about a cellular first laptop. If these things work as smoothly as the marketing makes them out, I’ll switch back to Windows in a heartbeat, no questions asked. I don’t care if I have to browse with Edge and use PowerShell all day, I want it.
If secure boot is disabled though, you have effectively the easiest ARM laptops to run other OSes on - single kernel fits all because it’s UEFI and ACPI based for basic device discovery. (Drivers become the hard part then.)
(Or more accurately: if secure boot is disable-able and/or lets you enroll your own keychain. Mandatory Secure Boot is no problem if you can control the chain of trust for secure boot.)