I used to be able to just close the lid on my laptop and forget about it for days. Nowadays with the new laptop provided by my employer, if I close the lid wrong, it doesn't even go to sleep and the battery drains completely (which is... understandable, I guess, since it didn't go to sleep) but even if I do all the rituals and it goes to sleep, the battery still drains away within a few hours. I can't full charge my laptop at the end of the workday, keep my VS and stuff open, and just the laptop to sleep. I have to shut it down properly and then start everything back up again the next morning.
I noticed that my HP only really goes to sleep if I close the lid WHEN UNPLUGGED (Windows settings get ignored or whatever reason). In case other laptops work the same, glad to be of help :)
So the device is (supposedly) awake enough to connect to the Internet, check for notifications and updates, but just not quite there to notice that it has been physically unplugged.
Thanks for that link. My ThinkPad X1 Carbon (gen 7) BIOS supported choosing Windows 10 or Linux sleep mode - I switched to "Linux mode" and now I have S3 sleep. We'll see if that fixes the issue.
I've battled this for a long time. The prospect of having my laptop be and stay charged is exciting.
It makes sense, because one of the modes of laptop use is to attach external display, keyboard, etc, along with power (2 or even 1 USB-C cable), close the lid, and work.
My employer disabled sleep entirely for some reason (not even available via the power menu), which means that if I forget to hibernate it before I throw it in my bag it’s concerningly hot by the time I get home.
What’s double weird is that, if I close it without hibernating it, not only does it not lock the laptop but it seems to prevent the “lock after x minutes inactivity” setting kicking in. Which seems like a huge security problem.
That happened to Ubuntu on my personal laptops, and occasionally I'd notice the mouse cursor was on a different position than when I closed the lid - I think the screen was somehow triggering the touchpad and that kept it awake/unlocked.
The thing is, when adding dependencies _isn't_ trivial, you end up vendoring. You aren't gonna thoroughly test your command line parser if it is a very small feature of your overall project. A dedicated command line parser lib will (more likely than you in this case) thoroughly test their implementation.
Live bug squash is better, imo. I was part of the production support at my $DAYJOB. My work was literally finding and squashing bugs all day. And yet, if you were to ask me for interesting stories, I won't be able to tell you anything. Maybe I'll remember the latest bug I solved but most of the time, once the bug is resolved, its off my mind. I will have to go through my jira and github history to first see which bugs I even worked on, then filter for the interesting ones and then try to remember the story instead of just the root cause.
> With zone-based, it could be the entire "west" zone that stops, which means you can't unlock the driver's door, open the windows, adjust the seat, and maybe even the ventilation fans don't work
From my reading, I thought the important parts were on their own dedicated ECUs (7 ECUs, 3 zones). Battery management, driving related stuff, infotainment, door mechanisms, etc have their own ECUs. The three zones are for smaller things that are probably important but not urgently important.
Actually they haven't. Using glob imports inside small functions can enhance readability without causing confusion. Otherwise any kind of aliasing and importing would be polluting the scope since they are bringing other items into your module without the full path.
I disagree, because the scope doesn't escape those functions and it can greatly reduce the amount of ::
Usually in an entire codebase or a module there's a lot of competing, similar symbols. But in a function that's not the case, because they do something small. So there's no benefit to being more "explicit", because the function already states what it does.
For example you might not want to use std::chrono. But in, say, a series of timing functions you really don't want to be writing std::chrono:monotonic_clock::now(), do you? You can just use a using and then just call now() or whatever.
I don't know C++ too deeply but from the little bit in the article, it seems like these `enum class` enums are actually Newtypes with associated constants instead of actual enumerations. They clearly don't 'enumerate' all possible values but they do give different behavior from their underlying type.
Is it possible to override the constructor so it limits the allowed values? Implement other methods on the `enum class`? If so then that makes them still very useful, albeit not in the usual `enum` sense.
The question is about who has the control and who has the responsibility.
There are users who want (or need) a curated, trustworthy experience. For them, an app store that heavily reviews all apps allowed on there and puts lots of restrictions on what they are allowed to do is ideal. There are also users who want to take the responsibility on themselves. They want the ability to host their own apps for free (or lower costs), faster update cycles, and just overall freedom. Those people don't want a highly curated app store (or rather, they want a co-existing alternative to the highly curated app store).
Perhaps the ideal situation would be that device comes with one default app store. That app store is highly curated and selective but it also allows other app stores on it. Those app stores can be reviewed in terms of their own quality but not on the quality of the apps they allow installing. The default app store can have huge warnings that these other store-like apps are not like the other apps and should be used carefully.
> There are also users who want to take the responsibility on themselves. They want the ability to host their own apps for free (or lower costs), faster update cycles, and just overall freedom. Those people don't want a highly curated app store (or rather, they want a co-existing alternative to the highly curated app store).
Why force Apple to make that App Store? This is what every argument like this boils down to. Apple are free to have their own opinion of what they want their product to be, and a tightly integrated experience is that opinion.
If users want something else, they can go elsewhere. If there is enough market demand for this, a company will exist and provide a product for it because that’s what companies do. But there isn’t, so they don’t.
No one is forcing apple to make that uncurated, open app store. They already exist. They want to force apple to allow that app store to be installed from their own app store.
> Apple are free to have their own opinion of what they want their product to be
While this would be fine in a free market with lots of competition, the market does not have that competition. Regulations are necessary so that the individual players in the market can't carve off their own separate realm. Apple is free to have a very tightly integrated experience with their devices and their app store and the very rigorously reviewed apps on that app store. It isn't like a non-default app store will destroy that. But that shouldn't mean that the users who are fine with a slightly less integrated experience for more freedom and control should be left without a choice.
> If there is enough market demand for this, a company will exist and provide a product for it because that’s what companies do.
There also needs to be space for such a company. No one (or mostly no one) will package their apps for a new OS so a standardised app format is required. No one will trust their phone number and identity and everything related to that to a new provider so a standardised way to switch the provider needs to be provided. Etc.
Make it so that I can switch out one part of the experience and the rest of it can't just refuse to work.
There is a competing c interface that numpy and a few other projects are adopting that allows for no gil. Last time this came up I thought the rust implementation used that one.
It is actually that. If you are including an svg using <img> then you can no longer, say, change the stroke color. It also does not inherit your css from the rest of your site even on first load. Your svg is treated like any other regular png or such.
Please review my earlier comment. “Styling properties of SVG elements via CSS” is, on reflection, slightly ambiguous, but largely refers to static styling, which you can do anywhere. If you’re talking about changing things, at runtime, you’re talking about the SVG being interactive, not stylable. And heritability is, as I remarked, another different thing, which doesn’t work for <iframe>, so that can’t be what it’s talking about.
But I’m not saying you can apply styles to the inside of an image from outside; that, as I have remarked, is a different matter, about heritability—you can’t do that with any technique but inline SVG. Not <img>, not <iframe>, because it’s not cross-document.
I (we) would obviously prefer the professional person who is doing good for society. The problem is, this behaviour isn't good for them. I am not an expert or anything but from what I know, pentesting without explicit prior permissions can easily lead to huge lawsuits. I would rather that the careless people get their cars stolen than the good people all lose heart completely.
Sure there is no perfect solution here.
I guess it’s a good idea to only pentest companies that do have a bug bounty program and an expressed interest in you pentesting.
While I enjoyed the article that GP referenced and agreed with most thing I thought the “hacking bad” take was a bit off.
reply