2,413 karma · joined June 4, 2010
https://ary.pub
http://campus.bethlehem.edu/centers/computer_center/Pegasus_...
There is almost a "brutalist" clarity to Windows 95 user interfaces that I miss.
Anyone who has grown up poor or known those who are poor has seen this in action. People will go to great lengths to not spend small amounts of money to the point that working for minimum wage would take less time to cover the expense.
When thinking about this problem I've not been able to get beyond the decision of "should it be done with something like a builder pattern and a graph of objects/structures" or "should it be done with a DSL" (which is what I consider the format strings approach to be). A DSL is more immediately convenient when creating output, but when you want to understand the structure you're emitting it seems better to have code that is explicit and imperative.
I wish people were less surprised when we tell them they deserve to be paid for their work, but companies have been advantaged in the hiring process for so long (excepting COVID) that disregard for people’s time is embedded in corporate culture.
However, to the point people have made about not getting comprehensive feedback: it’s just not worth it. Corporate counsel will basically refuse to let you tell a candidate why they were rejected for fear of any inadvertent lawsuit exposure. This is also deeply embedded in corporate culture and it’s hard to imagine it changing.
The opening statement doesn't bode well for the factual accuracy of what follows. Jobs was not a programmer, and Markkula was an investor, not a co-founder.
Tipping in this country should be called what it is: customer subsidization of service worker wages. Restaurants are allowed to pay their workers below minimum wage because of the expectation for tips. The answer has been clear for a while now. Require full minimum wage (not that it's enough) for all service workers regardless of their role and require that all tips be pooled for everyone working a given shift.
As others have mentioned the tipping culture in the U.S. has its roots in the abuses of the antebellum South. Tipping is paternalistic and many people treat it as a way to exercise power over service workers. It needs to be abolished, but as with most things we'll probably have to do it in phases.
The design should also fix the worst parts of using a box fan:
1. Make less noise.
2. Use less electricity.
1) We didn't spend a lot of time building something nobody wanted (which is the main theme of this post).
2) We experimented a lot with our product design because we knew we'd be getting feedback quickly and thus could take interesting risks. There was little "analysis paralysis".
Assuming you are your own target customer (in that you would actually pay money for what you're building) I think it can be too easy to conflate what you want to build ("this is fun/interesting") with what you want ("I need this and am willing part with money to get it").
This thread is a great reminder, so thanks.
This was a little bit of an uncomfortable read as I really didn't want to see this defeated, but I'm glad people are checking that it works as intended. The pessimist in me fears that when SIP bypasses are found this will be ready to go as part of a RAT. Realistically though the authors of RATs probably didn't need the example.
The linked gist doesn't appear to be making the case for using its recommendations in cryptographic applications so what I'm ultimately after is what the commenter thinks is being done in the shell that's inappropriate.
The use of "true" here seems ambiguous.
Does this statement mean that you discourage creation of cryptographic applications with shell scripts, you discourage use of shell scripts to orchestrate applications that use /dev/urandom for any reason, or something else entirely?
(first, and only edit: This comment is in good faith, so if you're downvoting please respond to let me know why)
Having been on both sides of the employment equation a few times now I can say confidently that people act on their values and respond to incentives without regard to where they sit on an org chart. This too doesn't require a study to confirm. Perhaps I'm naive and the point of publishing this is to drum up engagement from the aggrieved employed.
Be you an employer or employee the hardest thing to be in business is ethical. Convincing (or paying) people to care is incredibly hard, as is convincing (or paying) people to learn. It gets a lot easier when you find a way to tie either of those things to their values, and honestly most people, rationally, value themselves above all else. Is it any wonder people give up and begin exploiting one another?
This article reads like someone found the Gervais Principle [1] and viewed it as full of low-hanging fruit for a study.
[1] https://www.ribbonfarm.com/2009/10/07/the-gervais-principle-...
I say this as a long time heavy user of Little Snitch. It's very annoying when you first get it installed, but it provides really useful control over what installed software is getting up to. After a time you settle into a natural rule set for your personal patterns and only see alerts when new or updated software tries a network connection that hasn't been seen before.
"Mini" strikes me as much more of a fire-and-forget product, which I appreciate but won't personally use.
https://www.microsoft.com/en-us/research/uploads/prod/2019/0...
It's very much worth a read.
Nothing is wrong with things being available on Youtube or podcasts. The point is that much (if not most of it) is only available there and broadcast TV sits at the bottom of an ocean of emotion that exerts such extreme pressure that free thought cannot occur.
Personally I find any interface that can move while you use it to be borderline anger-inducing (the Google Cloud Platform console comes to mind immediately). In a car it's deadly. Gimmicks move gadgets though, so we had to let some designers and product managers get their bonuses/promotions and then pivot into an "epiphany" (sans the mea culpa) to get to now.
This is true, but it doesn't preclude use of the cloud.
The core of the cost issue is, in my view, that software is still designed to run in a datacenter: always on, all code in a single process (yes, this includes microservices), expected to never stop mid-execution. That made sense when you owned the hardware and needed to fully utilize it for the duration of its life. This prevents the best cost-saving measure in the cloud: turning it all off.
People can complain all they want about how the cloud providers operate, but there are ways to utilize cloud infrastructure without breaking the bank. Software development practices have to change, and in the meantime the cloud platform providers are going to make a pile of money as companies shift legacy software to the cloud without the needed re-architecture. We need frameworks and other technologies that, similar to the abstractions we now have for memory management, multi-threading, asynchronous I/O, etc. relieve the burden of reasoning around distributed, disjoint processes from the developer. Then we can finally realize the ideal of "only pay for what you need".
When it's time to negotiate your enterprise discount program, savings plan(s), etc., etc. you need leverage, and that's what this is. Some companies spend multiple hundreds of millions of dollars with AWS alone and at that cost any and every tactic to bring down spend will get deployed.
I should note that this question is asked in good faith, that I have attempted to ascertain the answer on my own, and I am very skeptical that the term has validity beyond self-aggrandizement.
It ended up saving us a lot of time.
1. It offered a resilient key/object store over HTTP.
2. By the standards of the day for bandwidth and storage it was (and to a certain extent still is) very inexpensive.
Since then much of AWS has been built on the foundation of S3 and so its importance has changed from merely being a tool to basically a pervasive dependency of the AWS stack. Also, it very much is designed for objects larger than 1KB and for applications that need durable storage of many, many large objects.
The key benefit, at least according to AWS marketing, is that you don't have to host it yourself.
Write operations (write, writev, pwrite, pwritev) are not currently supported. In the future, Mountpoint for Amazon S3 will support sequential writes, but with some limitations:
Writes will only be supported to new files, and must be done sequentially.
Modifying existing files will not be supported.
Truncation will not be supported.
[1] https://github.com/awslabs/mountpoint-s3/blob/main/doc/SEMAN...
[2] https://docs.aws.amazon.com/AmazonS3/latest/userguide/mpuove...
[3] https://docs.aws.amazon.com/AmazonS3/latest/API/API_CopyObje...
You may think that the approach doesn't apply to your market, customers, ideal user, etc., but I assure you that it does.
To be clear I'm not questioning the benchmark's accuracy or author's bona fides, but that post was a little short for my taste.
Whatever ways AWS marketing might encourage people to do things via their "Well Architected" series of publications, the reality is that the path of least resistance with VPC networking is what the linked article describes: everything on public subnets (with maybe security groups or network ACLs to restrict it somewhat).
Splitting infrastructure into public/private subnets is very tedious, and can at times be difficult to debug. In some of my most recent work it took some time to understand why and how the components needed to be linked to make a combination of an Internet Gateway, Network Firewall, and NAT Gateway work together. Combined with the use of multiple private subnets residing in different AZs meant testing permutations and fussing with the "reachability" analyzer. It is this kind of thing that makes people go with the first thing that works so that they can move on to getting productive work done.
Typically one wouldn't serve traffic via a NAT Gateway, and that's true for our case as well. The problem we ran into was not properly configuring VPC endpoints for a workload that heavily interacts with S3 and running up a tiny, but still not ideal, bill for network utilization over the NAT Gateway instead. It's not obvious to may people that interacting with AWS APIs happens over the public Internet even from within AWS infrastructure. The cost of ongoing cost NAT Gateways versus the free per-VPC Internet Gateway feels like it disincentivizes starting with a more secure setup.
Ultimately what I'm trying to say is that it's somewhat negligent of AWS to not make an almost universal requirement of modern web and SaaS cloud networking be simple and cheap to implement.