xemdetia

Is it? I feel like most of my atrocious cookie hand fix cases end up being broken redirects where you get redirected to some new url that errors, so loading the page doesn't help to get rid of the offending cookie.

I would say that it's more that Bash is good at something and JavaScript is good at other things and just because they are technically scripting languages doesn't mean that they are naturally a good fit in each other's domains. The README's comment tends to point towards an idea that all languages that can write scripts are equally interchangeable and of all choices JavaScript is the perfect choice. To people that are working on a variety of scripts in numerous languages who all have individual advantages and disadvantages, it comes off as nonsense.

I struggle to see how people are being effective with them because I do not see it personally and so much ends up slipping through the cracks especially in slack because it is impossible in the UX to keep up with the fact you might be:

- @-ed in a new thread and channel you've never heard of without context. e.g. '@yourname ^^'

- @-ed in a new thread in a conversation that has long since passed where all the discussion was done at the top level of the channel in a normal stream and you now have to deal with two paths of context.

- responded to in a thread that happened months/years ago with the expectation of immediate reply

- multiple people taking a linear conversation and starting their own threads thinking they are talking about different things which end up being the same conversation and having no way to merge these flows back together, then getting @yourname'd a month later and having to somehow find this adjacent thread where the actual conversation is happening.

- trying to catch up from vacation and having to try and mentally or actively serialize some number of days of communication temporally

Every Slack user in a business setting quickly becomes a power user if you are in orgs of 500+. I have no idea why the UX designers feel like everyone works on one thing at a time instead of being in a constant context switch hell which Slack's current UI does nothing to help. The thread views Slack provides are only the 'side view' and the 'thread list view' but you can't break it out into more windows if you need it. I am constantly in situations where I need to look at channels and two or more threads a the same time when trying to figure something out and I end up having to copy chat out of Slack into text editors just to stash a link/context/system output. Searching is also terrible- are you going to match the head of a thread or are you going to match the message right after it? You also can't look at a channel with 20 threads and see what you haven't read between last time you looked and this time. The best I have been able to do is keep a mental count in my head which only lasts a short while and not days. The thread list view is also terrible because it is a push and pull battle between unfolding threads so you can see what the heck it was about and then having to do it all again because you ended up having to switch contexts to answer a more immediate issue.

There is the restrictive protocol channel where every top-level message is distinct and any related message should be a thread message and that mostly/kind of works. I've seen that work OK as more of an ask-for-help situation, but it tends to also obscure what is happening if it there happens common cause outage. Everyone sees a different effect, but the root cause even if there is a pinned post added becomes not obvious because you can't actually visualize all threads of the conversation at once even if the person with knowledge is leading someone to water. Either way every channel with a restrictive protocol I participate in that uses this style loses a lot of its dynamic culture. You don't see who's regularly asking questions or follow-up questions that are actually of interest to you, you only see the bland post unless you click on every single link. I would enjoy watching channels on IRC because you'd find people who were answering questions and responding to follow-ups where the solid advice ended up being. Instead you can't passively find these things without clicking on every single thread and hoping you somehow infer this instead of it being plain and obvious. To that end even when I see that it is used effectively it is not something I think that helps people.

I lose context for 10% of all threads I end up needing to follow a week minimum (note *need* not want). I rarely lose context for anything that's posted to an actual channel because I can start at the top and scroll to the bottom and ensure I didn't miss anything. I don't want to click on every thread because often these threads have links to other threads and on other/same channels that I also can't quickly read through and find what I need to know. I always know when a channel hasn't been read and now that the Slack UI allows me to group channels in a sane way I now can efficiently loop through all the channel contexts I need to at the appropriate frequency of engagement. I also can't easily copy a block of channel messages and their children threads with just a quick copy and paste- and I end up needing to do that frequently.

After only two days this week of being buried in thread hell I would cry for joy if we went back to linear chat and using a ticketing system for any actual threads you need.

The discord post made sense because they understood what their workload was and did the type of 'classifying' queries that I previously described. They also decided to move off Mongo when they were hitting the 'real limits' of the underlying system from not being able to fit critical things in RAM. So they had a solid understanding of what was going on and they moved to rectify it. I don't want to presume to know anything about your sideproject but there's always going to be an limit you hit in any system, and you just need to build monitoring to understand when you are approaching that cliff.

They also had some clear characteristics of their system for their critical query that they could take advantage of: a new message is written to generally once, the messages table scales linearly, and updates and deletes are relatively rare. Using those things they were able to seek out a datastore that helped maximize the thing that's happening the most which is the write, and they were able to engineer a system accordingly. They also know that the messages would grow linearly without bound at a variable rate, so they could plan for that capacity. To me, that makes a lot of sense.

Especially if it is a side project you can't over-engineer capacity but you can do at least the measured math of what actions are actually happening in your system and what are your expectations for those queries. I would suggest that often times you'd want to focus on your critical queries that if slowed down would have the biggest net negative, but you'd have to find those. Every user action in a system should be attributable to some combination of reads or writes that can be reasoned about to try and figure out where there might be problems of contention, linear growth, exponential growth or growth up to a limit for a table, or something else. Either way, once you start classifying some of the critical paths in your system often either an answer or better questions start to come to the top. Without some of this information you can't back of the envelope whether or not your system can take a perceived load.

I would say that most resources would be a mixed bag in most situations but much of the advice skips over something very basic that experienced people tend to assume you know: you are always going to be limited by the number of times you can actually sync a write to a disk and/or how fast you can read back from the disk and these are the main upper bounds. One mistake I see inexperienced engineers make in modern environments is not realizing that in their particular cloud instance they are explicitly or implicitly using the cloud vendor's network storage and they are entirely hamstrung on that. The other is not configuring the database to use all the RAM- but those are usually covered by the existing tuning guides.

The next from a design perspective is to leave natural places to shard/split the data up so you could represent the data consistently on multiple systems. Sometimes it's pretty bonehead things like your database tables related to login are affecting your critical path transactions and/or also tied to the referential integrity of your application data in ways that are hard to split apart. It goes back to the IO thing where if you are reading and writing login or UI traffic you sure as heck are not writing some other critical time sensitive transaction especially if it's to the same disk. The other obvious thing is to be trying to run analytic queries (aka look at many records) on a database tuned for mass INSERT/write traffic and having no plan to do that with a different resource.

If you are still worried about it I would suggest just prototyping it using a currently modern API/RPC server in front of whatever datastore you come up with. As systems have gotten more distributed the straight line speed of connecting to the database directly makes less and less sense in my opinion and having an API server you control allows you to be clever later in ways that might not be obvious today (especially keeping application-aware counters so that you can see what your application is actually doing as query-style logs for databases are extremely expensive in performance). Either way if you sit down and consider the performance characteristics of the underlying system, think about each class of transactions are you considering from your application in a write/read context (hopefully from measured data), and using tools like EXPLAIN you'll quickly start finding what pieces of the puzzle might need to move to start scaling.

The answer also might just be some parts of your application would be better served something other than a database like a message queue, a more straightforward ISAM or key-value store, or depending on your situation just flat files written onto the fastest local storage you can get to then be later transformed and loaded into a database sometime later.

A campaign who's willing to do the legwork to actively identify potential customers/decision makers and advertise to them in innovative ways is perfectly reasonable. The issue is always going to be how they identified the targets and if the sources of data are ones actively consented to, which is different than what Facebook are collecting and providing. A lot of these firms are assuming consent and then reaching as far as they can, and that's always been the problem. I consent to plenty of sources of advertising data through contests, conferences, newsletters, accounts and actions on a particular service, public social media, and so on. If you want to aggregate that consented to information from multiple providers it is fine as long as their privacy policies make that clear. What I don't consent a single provider assuming they can just leech off other providers through device snooping/super cookies/other shenanigans. When some of these inputs are coming from these shady or overreaching sources the campaign itself and anything that's an outcome of that becomes fruit of a poisoned tree. If you look at it from that perspective what becomes 'good' compared to 'bad' becomes straightforward.

If facebook wants this correlating data for outgoing traffic they should be asking to buy it from individual providers instead of assuming consent and scraping it via a side channel on your phone.

I'm confused with claiming obscure emacs or vi commands for TRAMP, I'm from the emacs side and as soon as I understood the file path scheme (e.g.: /ssh:$host:/path/to/file) I didn't have to do anything beyond that.

I would say that the dev client/server setup you're describing and what TRAMP provides are different things overall as well. TRAMP really just provides a way to get a file from a remote, edit it locally, and on save write it back to the remote system. I would not consider it a valid use case for remote dev especially now with how prevalent things like LSP's are and I don't know of a major mode that is designed around a remote LSP I'd just do X forwarding or some other screen share at that point. I would agree that overall it's a gap for emacs that VS Code does better.

In other videos (especially for the prior license issue about resell of used goods vs. the repair license) he does seem to talk to lawyers who are familiar with the city rules but has reported not having great avenues to success. The problem seems genuinely tied to some parts of the city government still assessing fees/fines/so forth, but the COVID rules are preventing escalation/remedy in person in a meaningful way and the only way to get traction is to do so. The general vibe he's been putting out across the last couple months is just that he's feeling like he's getting shook down since in his perspective he's holding his end of the bargain with paying for licenses yet can't get the city to hold theirs.

I actually use the git-gutter.el package alongside magit to do the arbitrary region work, and find it to fill the last gap between magit and the built-in version control commands.

> It's a corner of the web that hasn't been fully co-opted and dominated by centralized trillion-dollar monopolies hell bent on quantifying your ad preferences while beating all divergent thinking out of you.

Yes, but in the view of an outsider who at least has some knowledge of what it's trying to accomplish it seems mostly dominated by people running pump and dump schemes, scams, and other activities of ill repute. As such it is hard to see it in a positive light, and in the solution spaces of most businesses blockchain doesn't really fit and is the worst kind of vapourware instead. Worse, a lot of the applications seem to assume a perpetuity of things where there's no clear path of stewardship (decentralized or otherwise) of what happens when people get bored of it or the network stops being able to meet it's intended goals. Most applications of blockchain require people to not be bad actors and exploit the system, unfortunately it seems to have attracted a lot of bad actors.

The only use I've seen that makes any sense is CT (certificate transparency), where it actually fits the model provided by the blockchain concept well. It's my only example of a relatively 'clean' blockchain tied to something useful and practical and helps even people that don't understand it.

People excited around blockchain seem to be excited with the community they created and I don't think that's wrong. However, it is hard for me to see that community worth personally joining when a lot of what you see discussed around blockchain ends up being bots, salespeople, scammers, astroturfers, or the misinformed. It's not inducing the same medium of creativity as lot of other web inventions like forums, flash, mobile apps, etc. It just ends up being about itself which is fine but nets limited interest which makes the negative actors stand out that much more. I'm sure there's pockets of genuine good here and there, but it's hard to see past the dark vile ichor that surrounds everything.

You need an external list anyway just to keep track of where things moved around to across subscription services. I wouldn't mind the current segmented streaming market as much if the people that are selling their media rights around provider to provider would do any effort to guide your eyeballs to their work, but they don't seem to be incentivized to do that and would rather direct you to a buy/rent situation instead which makes the whole streaming subscription piece redundant. Right now nobody's running the job as the promoter where they do an end to end hype train, it feels like everyone's just leaning on passive advertising and waiting to sell media rights to the next group. With the direct to consumer digital media purchase option only becoming more prevalent it seems like the subscription movies are going to be in purgatory for a very long time.

I disagree with this point because most interviewers and interviewees are novices, and giving them a task that gives straight pass/fail feedback optimizes for the wrong solution for people that can solve puzzles but not think about systems well. I've had many candidates be able to zip through puzzles but when asked relevant questions about building an understanding systems they wash out immediately. Most systems are more than one code file and I don't need to waste my hiring expenses teaching them how to think about systems from near scratch and having to heavy hand review them to write good code. I have generally found the only leetcode grind types to be less self sufficient and not really a signifier to success. In my experience the leetcode grind type can't even expand on their own answers to answer any useful questions like 'where and why would you use what you just made' and 'what technologies have you used that might utilize this technique' ends up with crickets. Right now my interview has a wash out coding exercise that is beginner oriented to get the resume liars but other than that it's all systems.

I agree that even middling quality middle managers provide plenty of value, but there definitely is a class of manager that does not know how to engage with all of their employee charges and make them effective. Most of the egregious side hustle situations I've run into have come from particular employees that felt they were so close to the chopping block that it didn't matter anyway, as they felt abandoned by their management chain either perceived or in fact. Most others have at least been respectful that the full time salary = time priority and because of that and reasonable task management it became not a problem.

I've become extremely jaded to the logo gallery for these obvious secondary/tertiary B2B SaaS products in an organization. The logo for a pilot or some other freebie is kind of overdone now. Often this pilot ends up hitting the real org then crashing and burning because these secondary/tertiary pet projects are often never given the chance to be mature enough for their actual customer base before trying to solicit customers. These services finally hit a security person or something else and just gets the axe because they are just not even close to ready. If I'm playing technical customer I'm reaching out to you because I need what you have rather than you soliciting me. Most businesses are not so complex that it's obvious if a B2B SaaS is an essential service or some weird add-on trendy thing they are trying on for size so it sticks out like a sore thumb.

Did anyone ask the lawyers about this one before they committed to this idea? I do not want a situation where individuals can have search warrants issued to Amazon who as a network provider can scan/canvas an entire neighborhood for a suspected crime. Encryption doesn't really cover the fact that it creates a universal backdoor to private networks that work with Amazon products. Just because they claim customer privacy does not insulate them from being served a legal order to produce records/provide access. This feels like a compute crime law nightmare.

I think you are approaching it from a different place than I am. If I get into an annual contract I have the expectation that I would be paying the full amount up front to secure the discount and that I would be utilizing the full amount of the term. If after six months I stop then that's for some new reason that was not there in the start. At that time I would expect a rebate for the services that would not be rendered. I could be a six month customer or a ten year and six month customer and have the same expectation. Things change.

I'm with everyone else that I would prefer to pay annually up front if the cost is not too high and having the service contract up for that period makes sense. From a more basic business flow I would expect that if you offer a straightforward $10*X/year plan that your expenses are built around that cost. I would expect the monthly cost to be higher to reflect the risk of not having a committed customer base and the overhead of getting payment from those customers.

As other people mention it would be assumed that $10*X/year would be billed upfront and that you would be 'paying' yourself out of that sum as each month is invoiced. Are you accounting for your liabilities vs. assets correctly and are still sustainable? Are you profitable month to month? Are you meeting your target income after expenses from whatever $10*X/year was supposed to be? Are you sure you are calculating all your expenses precisely from the prior calculations?

If you have 'yes' to all of the prior questions maybe you need to decide where you want to take your business in other areas. It might make sense to just focus on overall growth and not sweat this signal. It would be good to establish the churn rate individually for annual and monthly customers by activity as well as cancellation.

If any one is 'no' you might just have to raise prices because you have to raise prices because you're not getting out of the business what you expect. Raising prices to ensure that you are not just surviving but getting your piece is OK. At the same time maybe the price point is just a good price point and you could focus on growth.

More philosophically how would you subscribe to your service as a customer? If you'd say annually maybe it's just a service that works better annually. I would say Netflix is better month to month because the moment I stop using it is the moment it stops providing value, while a DNS name I have multi-year agreements on because even if I stop actively using it, it's still worth having the arrangement because I am paying just to have it be there for me.

I would go further and expect number 2 to be the norm. If I pay for a service and I'm allocated and the service is up and available for 6 months and I have 6 months left I would expect the refund to be 6 months and not from the beginning of the contract. They've already spent the money and you've already earned the money at that point.

That's interesting because I feel it's the opposite. Chrome ends up being the one that I have the most trouble with when it comes to usage nannying without providing overrides and removing features without thought. I don't think I've heard of a feature that was in core Firefox that was removed since quantum. Do you have a good example?

It's frustrating too because both Slack and Discord fail to adequately provide either multi-account or at least multi-client on the same host in a nice way. Because of the Slack workspace/Discord server sprawl I always run into a situation where I want to login to the community/people/work that I am focused in but some days you just need to be in two different scopes at once.

I think one of the forgotten blessings of PHP/CGI was that requests had to finish sometime so as to free the PHP process for the next request. This alone I feel ended up making decisions easy around when it felt right to offload stuff when slow requests started to affect index.php from rendering in a timely fashion but now that's often masked (rightly) by caches and other tricks.

Right now in a microservice model often you have to remind developers that it just isn't ok to have a ~1ms response in a basic case and a 1 second to infinitely blocking case during errors or slow remote services.

Out of the hundred or so resumes I have worked with at this point the handful that have had their github up that I had time to look at were net-zero or net-negative as an addendum of their resume. There's a difference between an engineer with a history of open source and one that 'did something and pushed to github', and most entry-level engineers haven't had such a strong history of open source that what you see of them would be meaningful anyway. I do try to preach this to what developers I come across but there's only so much that can be done.

I think people who haven't worked in/around IBM struggle to comprehend the sheer number of products and services it actively supports and only a portion of that are mainframe products. There are many products that have 100+ engineers on them but might never even make common conversation for how specialized they are. Additionally IBM has a high headcount for supporting those products, with 24/7/365 phone/hands-on support so that can sometimes be almost the similar number of people as the engineers actually developing the product. Since the products are so specialized there are specialized support groups per product. It's definitely easy to have 150+ people per product (especially from the heavy acquisition style they had been doing pre-Red Hat) so the numbers quickly adding up. Many of these groups have enough organization to transition to a standalone company's product team if they could replace the HR, accounting, and other company pieces.

There is certainly also consulting and other groups of people too, but they were not the majority.

I think you misunderstand the roadblock. Especially for any higher security like FedRAMP it is up to the FedRAMP certified holder to vet and have a very solid understanding of that remote service or system they are using at a moderate to deep level. Most sec people will do enough research to know if the service provider are at least an immediate no or not, but even if they are same-or-better FedRAMP level you still need to document them in your SSP (a system security plan for your whole org from HR to Engineering). This also doesn't prevent the situation that you then need to do a deep dive with this other organization to find out how FedRAMP their FedRAMP program like this, because more often than not organizations hide a lot of skeletons on what features/services are actually FedRAMP and what are features they intend to have FedRAMP 6-10 months from now.

Then you have to keep on them forever, and stay apprised of features people would like you to use but aren't FedRAMP appropriate yet or do not have appropriate controls. I think you would be surprised how many SaaS providers really don't meet the muster under scrutiny, or your engineering teams are trying to use features that just haven't been brought into compliance yet. For example, the number of times I have had to use https://aws.amazon.com/compliance/services-in-scope/ (click the FedRAMP tab) as a hammer is extremely high. Then you get on the phone with AWS and you find out that only a certain subset of the service that meets their FedRAMP do not provide adequate controls for your usage of the service. There's a lot of defer to vendor and defer to user games being played by both sides and you have to go line by line and figure out who is responsible for what. More often than not the service's people that are catering to the customer are not appropriately educated too, so there's layers of escalations by a security team just to get someone who can answer security questions accurately.

So no, a security person can only see from most organizations that you tried to attest to some of these random certifications, but that doesn't mean I have an accurate map of how I'm supposed to meet my compliance goals with your stuff.

(This is not aimed at any one provider in particular, just my personal feelings on where this 'internal roadblock' argument falls apart).

> Other companies take it as a feature demand. I find this bizarre, because I have barely (or never) used their product.

This is something that I've seen constantly from the PMP/offering manager/product manager types and have been in the room where it happens. The thing that is utterly baffling is that it's usually a vague intent from an interested but not current user but then the person writing down these imagined requirements asks zero follow-up questions in a complete disservice to the user. So for example 'does your product use AI' or 'do you have a slack integration' open ended questions turn into firm requirements 'to close the deal' internally but with a completely headless goal. When I am usually in the room I at least give the customer the dignity of trying to work out what their idea/perceived benefit is with them so I can accurately transmit the knowledge to the team. Often someone more experienced with the product's offering can solve the real customer use case with existing features that just doesn't have the same label.

My favourite firing of a software company was when they expressed that they were refocusing from clear stability initiatives to machine learning driven analytic dashboards. This was even though this was a customer retention meeting company to company that was spawned over threats to not renew... because of stability issues.

Having been in a similar position usually being on the 'inside' with access to code/tools/etc was more interesting than being some consultant who didn't have sufficient access and was saddled with the job responsibility of actually using the product for it's intended goal in an ordinary business setting. Playing troubleshooter for the real hard problems that nobody expected or thought about and delivering a solution in one in a hundred calls can be more rewarding than just turning the crank on a business system.

> Personally I find it better for non technical people, because they can focus on the domain only. For tech people you have the option to keep the full url visible at all time, which fixes the issue.

I think a large part of my repulsion to this change is mostly because Chrome has a history of removing options constantly. A weird default with a setting to get to more expected behaviour is fine, but I have no faith in them to not remove the full url visible at all time option at this point.

Yeah, there's no discussion on this blog post of what a lot of people are doing in writing project-specific linters, static analysis passes, code generators and so on that just ensure higher code quality which to me is more bleeding edge when it comes to actually helping. There's also no mention of the fact QEMU is tightly bound to other C based projects like libvirt and KVM and having developers be able to switch back and forth is extraordinarily useful. It wouldn't just be replacing QEMU but also the ecosystem around QEMU. It's not like QEMU is the application at the end of a dependency chain, it's in the middle for a lot of users.

This definitely has been bred from 'fitting content creation to the algorithm'. There seems to be many dimensions of this with the first being maximizing minutes watched which is where the meandering and stumbling content seems to come from. The second is monetization and knowing if you have to dispute it's essentially already too late, re-uploading is punished heavily and the algorithm heavily favours new content. The third is people observing that to get reliably recommended having a strict upload pattern seems to be favoured by the algorithm which can turn into 'produce to produce' instead of a creative effort. The fourth is just the overhead of dealing with claims and other weird administrative backend and/or YouTube making a sweeping policy change that generates dozens of hours of manual work for people with a large catalog. The last is that because of all of these previous problems many of these people moved over to twitch and then just use their old YouTube account as a clip/advertising mill/stream archive dump site.

I put a lot of the blame on YouTube, because people seem more than happy to reward/watch well produced content but YouTube's algorithm rewards daily junk content over polished content produced biweekly or monthly. You can see glimmers of old YouTube from time to time where the video is trimmed precisely to support the actual content even if it's 3 minutes or well edited to be engaging but YouTube keeps creating (and revising) a game where that kind of content loses.

In my personal observations of the matter it is more that it's just a different kind of celebrity than their original draw. Nobody earnestly cares if some hollywood star becomes a professional golfer, singer, or race car driver. They have to build themselves up anew to this new audience who is selecting 'celebrity status' by a different set of rules and criteria. Now if someone in hollywood moves to another position within hollywood like actor to director hey are still closely related to the same rules of selection so they get a boost just from qualifying to what the audience is looking at.

Given that this is where there is just a separate group of people that understands or learns the selection criteria for YouTube/Twitter/TikTok/Twitch whatever and can have more synergy transferring between these outlets. It makes sense that someone who in another setting is popular just seems to land flat when they are having to relearn a new way of presenting themselves and the old tools don't work. Even celebrities that start a YouTube channel that I at least followed in passing end up feeling terrible, and I don't think I've seen a hollywood grade external star stick with their YouTube content long enough to actually start learning what needs to change.