A vector is a vector :) Imagine someone with just user privilege to a machine needing admin access to install more pervasive RAT, this gives them a way.
>vulnerability was caused by hh.exe, but they were told that if there was a command injection from hh.exe, a child process should be created under hh.exe, so especially the heap-overflow side of this vulnerability will not be shared with the community.
"Due to community security, it will not be published until the update is passed. Maybe it will never be published :)"
>edit: I personally think the author did a great job finding & publishing it.
Not really.
They seem to be implying they got to running a command as SYSTEM from 7-zip, but, like, don't specify things like what security context 7-zip started as, or how a program running as non-admin got to a system security context, or like, how that's 7zip's fault and not the fault of the OS.
This is all very confusing.
Even if all they did was took that screen shot from process explorer and expanded it to include the user column, it would be like 99% more clear what the fuck is going on.
"Linear Algebra: Gateway to Mathematic" by Robert Messer. I'm not sure it's particularly great, but it showed me a level of elegance I hadn't seen in CS at that point. So I switched my minor to math and hasn't regretted it.
I work for a company that is owned by and serves pension funds. If I do my job well, it means better retirement savings for nurses, teachers and kindergarden teachers. That's pretty motivating.
I wish my dishwasher could automaticly start whenver the price of electricity was low. I can manualle delay it by doing simple math in my head and forecasting prices, but it would be easier and more foolproof if I could script it with IFTTT.
Your dishwasher probably uses ~1kWh of energy per cycle. Unless you're running your dishwasher a lot, or you're in an area where the difference per kWh is really massive, you're really not saving that much money.
Yes that does get you 99% of the way there at least. It does require predicting/assuming the electricity prices though. If they are predictable enough, that's fine. It doesn't quite reach feature parity with actually fetching electricity prices every hour and slowly learning when it's cheapest over many weeks.
Not sure how much prices can vary over the day, and more importantly how that varies by weekday, season and so on. How much you can make by having an online price service varies with how well you’d be able to “hit” the price dips manually too.
It starts with the Singleton and vaguely hints that it has some drawbacks. Why start with that, then? And why not flat our recognise that it is understood more as an anti-pattern these days?
I don't get blogs like these. This story has been told a million times with more or less the same content and structure.
> It starts with the Singleton and vaguely hints that it has some drawbacks. Why start with that, then? And why not flat our recognise that it is understood more as an anti-pattern these days?
There might be significant tradeoffs with singletons, but I wouldn't go as far as claiming they are an anti-pattern. Far from it. Managing and sharing a single instance across the whole application is a critical part of other basic software architecture constructs like dependency injection or even handing app settings.
You misunderstood the singlenton pattern. It's not about "Managing and sharing a single instance", it's about only being able to instantiate one instance of a class. That's not the same, because you can achieve the former without having the latter.
> You misunderstood the singlenton pattern. It's not about "Managing and sharing a single instance", it's about only being able to instantiate one instance of a class.
Not quite, you're confusing a particular way a singleton is implemented with the whole purpose of a singleton and why there's a need to restrict a class to have a single instance to begin with.
To illustrate your misconception, you can instantiate a regular class as a global variable and specify that no other instance is allowed in a project in the project's coding standards to enforce this at the code review level, and you still have a singleton.
The whole point of a singleton is that only one instance of a class is used across the system, regardless of whether this is enforced by any technice or not.
Don't confuse a specific implementation with the purpose, and requiring/expectinv only one instance of a class to be available is obviously not an anti-pattern.
> ...requiring/expectinv only one instance of a class to be available is obviously not an anti-pattern.
I'll disagree. There are very few situations where restricting class instantiation to one object both solves a problem and doesn't cause unneeded headaches.
Almost always a boring global with careful access control is better. It provides a single object just as well without limiting options for future software engineering needs: testing, adding construction parameters, migration, gradual deprecation, etc.
As to legitimate uses, anything with system scope can't be controlled within a process. And there are few things that inherently couldn't be instantiated twice that aren't better managed by the OS.
> Not quite, you're confusing a particular way a singleton is implemented with the whole purpose of a singleton and why there's a need to restrict a class to have a single instance to begin with.
Have you actually read the definition(s) of the singleton pattern? E.g. Wikipedia: "In software engineering, the singleton pattern is a software design pattern that restricts the instantiation of a class to one "single" instance." (https://en.wikipedia.org/wiki/Singleton_pattern)
And it's the same in most other definitions.
Also, make sure to read the criticism on the Wikipedia page - I think the criticism there is enough to classify it as an antipattern, because again, it's not about just having one instance of a type/class.
> Have you actually read the definition(s) of the singleton pattern? E.g. Wikipedia: "In software engineering, the singleton pattern is a software design pattern that restricts the instantiation of a class to one "single" instance."
Yes, I did. I also know what a singleton is, and the whole point it's a thing. Did you read my explanation were I pointed out your misconceptions?
> Also, make sure to read the criticism on the Wikipedia page - I think the criticism there is enough to classify it as an antipattern,
You should first take your own advice into consideration and first read your sources before citing them. If you did before succumbing to your appeal to authority, you would have noticed the fact that your whole argument that singletons supposedly were an anti-pattern is what, and I quote, "it is frequently used in scenarios where it is not beneficial" because of the global state. Do you understand the problem with the way you're trying to generalize an assertion, specially given that enforcing a global state is often the whole point of using a singleton? If you fail to understand how/why/when a technique is used, that does not make it an anti-pattern.
Lastly, please get acquainted with HN's guidelines on commenting as your last comment goes against a few principles stated in them.
We are talking about design patterns here, about the singleton design pattern. And not just about singleton objects. You still seem to mix up the two things.
> Lastly, please get acquainted with HN's guidelines on commenting as your last comment goes against a few principles stated in them.
I think you are just misunderstanding me (and the OP) and I'm trying to clarify. I don't see which principle I would violate with that.
> We are talking about design patterns here, about the singleton design pattern.
I appreciate your attempt to move the goal post and gaslight, but it's already readily apparent that you're very confident in your misunderstanding and misconceptions, and very resilient to their clarifications and corrections. You're free to learn about the basics of design patterns if you'd like but until then I see no point in continuing this discussion.
> I don't get blogs like these. This story has been told a million times with more or less the same content and structure.
Yes, but things like this need to be repeated every few years to show it to a new generation of coders.
30-40 some year olds of today have probably been exposed to the original design patterns book already, but a younger generation grew up and worked with different tech, e.g. ruby / python / php, where these design patterns were reinvented.
I mean Ruby on Rails and some PHP frameworks from the 2000's / 2010's reinvented the MVC framework / design pattern, I had never heard of it before until these came back with it, but it's a pattern from the 70's apparently.
It's not to pick on you, but why do people spell it with a capital S?
I've seen it in several comments over the years. But their spelling and logo, at least going back to the 80'es, have been "Microsoft". I think they might have been "Micro-Soft" for the first year, but that was 45 years ago.
MicroProse, on the other hand, went with the capital P.
I actually do write Microsoft usually. I’m not sure what came over me. I was a tired when I wrote the original? Maybe typing out GitHub and SourceForge triggered a StudlyCaps LoveFest in my brain. Thanks for the correction.
With is what WD are doing, having just been caught changing parts in a way that impacts performance
> A Western Digital spokesperson confirmed to Ars that the company had replaced the NAND flash and updated the firmware in the WD Blue SN550 beginning in June 2021 and updated the drive's data sheet to reflect the changes. "For greater transparency going forward, if we make a change to an existing internal SSD, we commit to introducing a new model number whenever any related published specifications are impacted"
I work in hardware design. Almost all ICs are very very limited supply. In our own case we had to move from 512K MCU to 256K simply because lead times are now until Dec 2022 on the 512K version.
I'm really surprised this hasn't bubbled-up to normies yet. I suspect this Christmas is going to be a shocker.
That is both unnecessarily rude, and missing the point the parent post is making.
Companies want to use whatever they can get that's vaguely compatible with the current design. Because it's that or selling nothing for 12 more months.
Sure. But that is not an excuse for misleading the customer. Couldn't find any components wich perform equally well? Then it's a different SKU. Slap a suffix on the name, adjust the price as needed, and don't mix inventory.
(Seriously, what's with the writing in the article? ChatGPT can do better.)