Just remove the DRM chip that’s located on the starter cartridge, mine was on with a small Phillips screw. I then used the Brither DRM chip on my Linkyo toner cartridge and it works a treat. Problem solved AFICT.
Intel lost this battle years ago when leadership decided to badge engineer the shit out of their product portfolio and do stock buy-backs. In a capital intensive enterprise, Jack Welch school of management will only give the company maybe 10 years before those opportunity costs blow signifgant holes in your boat. Look at TSMC, they take government money, invested that in people and material. They’ve got a work plan in place to meet their customers needs which in turn is driving market direction. GF was left for dead and look at what they’re doing. They’re eating Intel’s lunch now while they’re flailing with mediocre graphic cards and no clear strategy where they’re going with future x86 designs. The universe is moving towards RISC and they’re essentially locked in a prison of their own making.
Of all the things you picked the least relevant one. Intel without GPUs is dead. Gone. Zero. A foundry at best, with a decade to be top tier again. Intel without RISC is… fine? The instruction set doesn’t matter, the underlying hardware doesn’t execute it anyway, it runs microcode.
I have some that's pale pearly gray. Not sure if they just cheaped out on a colorant or something, but it's definitely bargain-basement stuff so that wouldn't surprise me.
You're correct, just about all "new" cassette decks contain Tanashin-originated components. Even reputable brands like Panasonic (National), TEAC, Son, Aldi & AllyExpress all use the same crappy mech.
Techmoan has been shown that nearly every "new" tape-playing device these days all contain the same lousy mech, some not even capable of stereo playback!
VWestlife covered the "world's first Bluetooth capable portable cassette player" which is a few years old now but also uses a lousy mech (mono!).
Cassette audio today seems to be more about the experience and social aspects of making, trading, and playing tapes ( Ala Guardians of the Galaxy style )rather than getting the best quality audio.
Does it matter what tool you use to write documentation? Confluence gets a lot of sh*t because its in the grown-up camp of tools but I know people who've got problems even with nano.
It's incumbent upon all users or members of the team to use the common tool along with agreed upon standards. Otherwise even if you wrote documentation in your own hemoglobin, no one would touch it either.
Some manager prob chose _________ as the tool for ticketing, documentation, etc not because it was good at ______, or _______ but because it fulfilled their action plan to have something, anything in place so that if the universe goes supernova, well some stuff was written down.
In my journey it seems that nobody is willing to criticize Edward Teach for the lousy treasure map he left, but rather we make fun of those who're still looking for his stuff.
It does matter because the issue with wikis (not just confluence) is there's no approval or review workflow. Imagine trying to write a large program in which everyone could just commit at will, with no review process whatsoever, and where nobody had made any decisions about design up front. There'd be duplication, dead code, the organization would be crazy.
That's the average wiki. It's a commons and a tragic one. To make docs work you have to treat it more like a codebase: clear ownership, standards, review processes, approvals, up front design, refactoring efforts etc.
> To make docs work you have to treat it more like a codebase: clear ownership, standards, review processes, approvals, up front design, refactoring efforts etc.
Maybe true in large orgs.
But for smaller companies what I've seen is usually paralysis.
e.g. someone notes a problem (maybe just a typo) in the doc. Can they fix it within seconds? If instead they need to raise a ticket then most likely it ain't happening. They move on, and the next person experiences the same problem.
IMO the default should indeed be towards everyone committing at will. Yes that will result in the occasional snafu. Fix that when it happens. (obviously not good practice for the operating manual for a nuclear power plant - but for a <500 person Saas company it is).
Mandating a Jira ticket for simple typo fixes is overkill. But if you make it easy to create a PR directly on the documentation file, without leaving the tab, I don't see an issue. This is already a Github feature.
We did PR's on documentation files at my last place, it worked but it was more painful than getting reviews for code PR's. Tickets work because they can be reasoned about, shoved aside, brought back into the limelight, updated, other tickets can easily be related to them as more information is discovered, etc.
Overall the comments on this page fall into 2 camps, people who've tried it all and found what works is discipline and those who are still trying it all.
Disagree. A ticket should be created for any change, no matter how small. It takes seconds to write a title, body and hit submit. I've seen those small ad-hoc changes cause havoc because someone forgot to escape a single quote or didn't realize tabs were necessary and replaced them with spaces.
The default for Confluence is just that, everyone commits at will. There is no structure, tons of duplication, no standards when it comes to naming, formatting, audience, etc. I'm a huge fan of markdown/plain-text solutions, only because linters can be run that force you down one happy path. I don't believe Confluence has linters at all.
Yep, and that process also involves other people, to review/ approve the fix to the typo.
It then goes from being a few seconds of elapsed time and actual time (to just commit a fix to the typo) to taking hours, days or weeks of elapsed time and hours of actual time and forcing context switching on, and interrupting the workflow of, all of people involved.
The last thing I want is to raise the friction for writing down documentation.
It's hard enough to get technical minded people to contribute to a git (or style) based knowledge base.
Pick your poison I guess but I'm quite happy to have testers/BAs/directors/etc able to quickly jot down thoughts roughly than have it disappear into the ether.
> The last thing I want is to raise the friction for writing down documentation.
A better solution might be that anyone can write the documentation, and there is a maintainer who constantly refactors the wiki to keep it legible. Makes sure the information is not duplicated, adds hyperlinks to things, etc.
"Everyone's responsibility" sounds like an euphemism for "no one really cares". When people actually care about something, they hire an expert.
Why do you hire software developers, instead of making software development everyone's responsibility? Is that because most people suck at software development? Well, most people suck at writing documentation, too.
I mean. I guess? The difference between having it written down in Confluence and disappearing into the ether is academic though. Either way nobody will ever find the information again.
There are some really nice git-based wiki systems out there, and one is built into GitHub and GitLab. If you want that type of workflow for your wiki, it's easy to get.
Unless some government(s) steps in and dumps a ton of money into SST development and production nothing is going to happen.
The Concord showed this by shouldering the burden of research, development, prototyping, and then production. Turns out SS's don't have the load factor & associated economics to make it a viable mode. That revelation was before environmental and political challenges made those economics worse.
Unless unobtanium can me mined, tooled, and manufactured cheaply into airframe parts and power such as scram-jet or super cruising turbofans can push a plane at Mach 2 with 200+ seats behind the pilot, methinks its just a pretty artist's conception on a Pop Mechanics or Science magazine cover.
Boy, did Nokia elope after this with M$ft phone which was supposed to right Nokia's collective "ship". Elop joined the hallowed hall of fame of abysmal CEO's who ran their firms into the ground. Remember Lumia, Windows Phone 7,8 & 10 blehh.
I had a Windows 8 phone from Nokia around 2015 or so and other than the lack of apps it was a phone like pretty much any other at the time or even these days. By that I mean I don't remember anything really bad about it, especially because I mostly use the web anyway.
I have no idea why things succeed or fail and so I don't know for this either, but my guess is it was new, but didn't have anything that provoked an interest with mainstream users. And Microsoft does not have many faithful users.
I wonder if they threw in the towel too soon. I too had a Nokia Windows phone and I loved it. They were popular in South Africa as Nokia was a recognised brand. Bandwidth is still expensive here so most people just need WhatsApp and Facebook and they are fine. Perhaps the developed market needed more apps.
It didn't matter how good or bad it was, Windows was a toxic brand on mobile. A very large segment of potential customers was rejecting it off hand based on their desktop Windows experience. They may have been stuck with it on the desktop but on mobile even if they weren't sure what they wanted they definitely knew that it wasn't THAT.
Ignoring the primary issue Uncle Sam has with this logistics solution, be reminded why laws and or regulations exist for things... there's always someone (right or wrong) that will circumvent the rules with shall we say... creative solutions.
This is where judges and spirit of the law come in. Laws hav always been imprecise and one remedy for that are judges and trials. I doubt what the company is doing will hold up in court if they want to argue that they satisfied the provision of the Jones Act.
My first real interest in computing came from my Uncle showing me his DX7. It made such cool synths as well what I thought at the time was a decent piano sound especially in the early 80s. A Huge bulky instrument it also had a midi interface too which was new (yikes) at the time.
Wow, that's great. I wrote a printed circuit layout program in SuperCard. You basically drew your program in the card layout editor using a few allowed shapes, and it just looped through all of the shapes on the card and translated them to Gerber files. The color identified top or bottom copper. When I got my first boards back from the fab, and they were actually what I designed, I nearly fell over.
