01.17.21

InteLeaks – Part XVIII: Intel Does Not Know How to Properly Do Research and It Seems Apparent Unscientific Methods Are Used to Justify Poor Documentation

Posted in Deception, GNU/Linux, Hardware at 5:45 pm by Dr. Roy Schestowitz

Video download link (see this series’ index for more)

Summary: There appears to be a severe crisis at Intel; they cannot recruit scientists (or those whom they recruited are walking away) and as a result the company produces bad products with poor documentation (or highly defective chipsets that top-notch marketing cannot compensate for); in this video we walk through some examples of how studies are being conducted (as already noted in Part XVII)

THE wiki page for this series is growing longer and the number of items we wish to show is increasing. This past week our videos were viewed about 65,000 times and we’re receiving feedback from people who know “Intel inside” (or what’s “inside Intel”). As noted in this latest part, much of what’s happening at Intel can be found in other companies too, albeit less accentuated. Many readers have seen/experienced it firsthand.

“For Intel not to be able to hire a full-time person with GNU/Linux knowledge and technical writing skills is a bit of an embarrassment.”
      –Anonymous
The risk for Intel is that by alienating GNU/Linux developers it lets other companies take advantage and take the lead. As one former insider told us about part XVII and prior parts, “reading this article series makes me realise how hard it must be to acquire people with GNU/Linux knowledge and to retain them, my employers were always begging me to stay on even when I had already decided to leave (for similar reasons as mentioned in this article series) and [...] this does seem to be a bit of a battle between business and technical people who will be at the top of current and future companies.”

In other words, according to him, “the suits fear they are losing out in a tech-savvy society…”

“For Intel not to be able to hire a full-time person with GNU/Linux knowledge and technical writing skills is a bit of an embarrassment,” he concluded.

01.16.21

InteLeaks – Part XVI: Intel Cannot Do Command Line, Even When It’s Vastly Simpler and More Suitable for Development

Posted in GNU/Linux, Hardware at 5:51 am by Dr. Roy Schestowitz

Video download link

Summary: The Developer eXperience (DX) team at Intel seems to be full of Microsoft drones instead of developers and/or mildly technical people; this has not only harmed the quality of documentation but also upset staff, alienating people who actually understand what developers need (more than buzzwords like “DX”)

THIS series is expected to run well into February. We’ve got plenty more to show as we learn more and more. People reach out to us. For a roundup of what we’ve already covered see the index in the relevant wiki page.

As one person put it yesterday: “Intel tried to hire me for a job at the Data Centre Group from my job at an Oracle/Microsoft data-centric company [...] it was always Oracle and SQL Server on Windows that were causing us problems” (an experience I can share too).

The above video focuses on poor documentation and bad advice from the Developer eXperience (DX) people at Intel. They refuse to listen to people who actually understand developers (like themselves) and the underlying platform, GNU/Linux.

We should soon be in a position to discuss, based on hard evidence that we have obtained, Microsoft boosters guiding Intel’s management. Microsoft is acting like a Trojan horse or a parasite, even in companies as large as Nokia and Intel.

As it turns out, Intel and Microsoft have much in common. A person named an example of that yesterday.

“Intel is also trying to ‘parasitise’ on other institutions and companies,” he said, “as last week someone in another channel mentioned the company being involved with quantum computing without being aware it is actually universities and academics doing most of the work…”

01.15.21

InteLeaks – Part XV: Intel is Blind to Blind and Colour-Blind People

Posted in Deception, GNU/Linux, Hardware at 10:26 am by Dr. Roy Schestowitz

Video download link (see this series’ index for more)

Summary: Intel does not seem to grasp very basic concepts associated with accessibility; nevertheless, Intel shamelessly tries painting itself as “woke” and a “justice warrior” (policing speech while overlooking much-needed practical work)

MANY people are not familiar with colour blindness; some never met any colour-blind people (or don’t know that they did). Some of us are fortunate to have worked both with blind people and colour-blind people. It shapes one’s views (no pun intended) on the subject. Does Intel have a vision? Other than In(tel)Vision™? Seems not.

“Intel, with its arrogance and its sheer (notoriously so) Hubris, is actually a lot more blind than people whom we call “blind”, who are compassionate and caring.”The above video, which took 5 hours to upload (our broadband issues are unfortunately back), deals with concerns about Intel’s lack of understanding of blind people. This complete lack of understanding, which relates to Intel’s inability to recruit suitable people, is causing harm to the company’s reputation. It’s widely known that accessibility aspects are exceedingly important; while Intel viciously lobbies to eliminate supposedly ‘racist’ words (many aren’t, unless viewed from a racist’s eye or mind) it has a serious oversight and insiders have been kind enough to point this out politely (only to be reprimanded and severely punished for it). We have plenty of high-profile examples of Intel doing this inside Linux, especially the kernel (these examples were covered here in past years).

“And it’s not like Intel lacks money to actually give a damn about accessibility, it’s just that it doesn’t care.”As someone who spent many years donating to blind people’s charities every month, this aspect of Intel’s incompetence actually annoy me vastly more than all those supposedly ‘offensive’ words that Intel employees work to remove (as if that will practically accomplish much, if anything at all) while mostly ignoring people like my blind colleagues and friends (since school days). Intel, with its arrogance and its sheer (notoriously so) Hubris, is actually a lot more blind than people whom we call “blind”, who are compassionate and caring. In the face of great hardships and ordeals, too. Intel is attacking charities (for profit). And it’s not like Intel lacks money to actually give a damn about accessibility, it’s just that it doesn’t care.

As a former Intel employee put it to us (earlier today), “what I do think is harmful is to put more importance into sticking with certain proprietary tools over accommodating your actual employees and customers [...] I worked at several companies that were so tied into the Wintel paradigm that they just couldn’t see a better way of doing things if it hit them in the face and dealing with these proprietary tools as a free software person can and does take its toll on you…”

GNU/Linux command line tools are actually renowned for accessibility aspects (very standardised and text-based, good for screen readers). That’s what the GNU/Linux folks at Intel had put in place before people from above decided to tear everything apart.

01.14.21

InteLeaks – Part XIV: Technical Incompetence and Incoherence Leading to Alienation and Brain Drain

Posted in GNU/Linux, Hardware at 7:42 am by Dr. Roy Schestowitz

Video download link

Summary: The idea that Intel “loves Linux” or “supports Linux” is somewhat of a sham; one needs only to consider what Intel insiders are saying about that, having witnessed it firsthand

THIS video starts with a few notes or mental notes (memories) regarding the demise of Intel, based on this week’s news (so far we know about a new CEO, as noted in our latest batch of Daily Links and more upcoming news picks). Intel has a job and talent retention crisis. It’s very well aware that in some circles/areas of operation it has grown increasingly irrelevant and fell way behind. That’s why they’re putting a new CEO in place (he comes from the most notorious GPL violator) and there are some big layoffs in a company half owned by Intel. We’ll link to reports about it in the next batch of Daily Links and this morning I heard about this from people with contacts inside the company (so it’s personally corroborated). It’s pretty serious, no matter what Intel tries to tell the public (or shareholders), and there’s more to come. I spent 20 minutes on the phone.

“Intel has a job and talent retention crisis.”This video deals with lack of understanding of GNU/Linux inside Intel. It also shows poor documentation efforts, which alienate and upset whatever geeks still work at Intel (there seems to be ‘brain drain’; see this series’ index in the relevant wiki page). Later in this series we’ll show some of the things that cause Intel engineers to hand in their notice; One of them wrote: “dropbox?! github?! slack?! We’re going to lose devs… I just use a shell, irc and gitlab but for change… why not an internal git of our own…”

“It’s inadvertently also a cautionary tale for other companies.”Intel will pay a very high price for trying to impose Microsoft on people who focus on GNU/Linux in order to get away from Microsoft. Of course Microsoft isn’t going to save Intel, nor will the new/incoming CEO (term starts or becomes effective very soon). Maybe nothing can save Intel anymore. It has long been committing felonies and nowadays it persistently makes a bunch of suicidal decisions/moves. The public needs to see it and insiders ought to know who’s responsible. It’s inadvertently also a cautionary tale for other companies.

01.13.21

InteLeaks – Part XIII: GNU/Linux Documentation From People Who Never Even Use GNU/Linux

Posted in GNU/Linux, Hardware at 10:05 am by Dr. Roy Schestowitz

Video download link

Summary: Inside Intel there’s a whole bunch of embarrassing secrets about the Developer/Development eXperience (“DX”) team; no wonder documentation efforts have been lacking and far too much time wasted putting such documentation together

THIS is the thirteenth part of at least half a dozen parts (see our index in the relevant wiki page). It deals with inside affairs at Intel and it sheds light on a situation so grim that we’ll need documents to properly expose it. We’ll get to that later in the series.

“Intel worked extra hard to squash voices and restrict dissemination of such material, knowing that it’s likely true/correct/accurate but rather embarrassing to Intel.”Today’s video, unscripted as usual, deals with the sorts of useless feedback developers at Intel receive from the “DX” team — basically a bunch of “low-tech” or non-tech people who assess documentation with inadequate proprietary software tools and a complete misunderstanding of what developers need and want. Intel worked extra hard to squash voices and restrict dissemination of such material, knowing that it’s likely true/correct/accurate but rather embarrassing to Intel.

01.12.21

InteLeaks – Part XII: Intel Isn’t Interested in Improving and Instead It’s Shooting the Messengers Who Highlight Areas for Improvement

Posted in GNU/Linux, Hardware at 8:52 am by Dr. Roy Schestowitz

Video download link

Summary: It seems rather clear that Intel (quite frankly like many other companies but perhaps even more so than the rest) isn’t interested in self-assessment and instead it’s looking to muzzle or even oust constructive critics

THERE’S not much to say about the material presented here other than to show it in full resolution, or in its raw form. My ramble cannot add much in this case, so instead we’re prearing to publish some originals, probably in the form of images slightly redacted. On the issue of Intel’s disdain or disrespect towards developers we’ve already covered a great deal of examples (see index in the relevant wiki page).

There’s a bit of a side story to all this; The GNU Linux Developer Experience (DX) material was frowned upon and led to disciplinary action, which relates to the material in this latest video. Basically, Intel is simply incapable of accepting constructive criticism and instead it is shooting the messenger, burying the underlying issues as if they never existed and insiders are foes whose arguments lack merit. “A little over 24 hours later,” one person told us, “the author’s access to mail, badge, and other systems was prematurely disabled.” That’s the author of those notes.

It’s pretty Clear Linux (pun intended) doesn’t matter to Intel. All it cares about is Intel and the people in its “Linux” divisions are bossed if not policed by people without the slightest knowledge about GNU/Linux. They frequently call Linux directories “folders” and can’t comprehend basic commands.

01.11.21

InteLeaks – Part XI: Accountability Issues and Disdain for Views/Opinions of Actual GNU/Linux Users/Developers/Communities

Posted in Deception, Free/Libre Software, GNU/Linux, Hardware at 7:25 am by Dr. Roy Schestowitz

Video download link

Summary: The truth about internal affairs at Intel and developers’ struggle with “low/non-tech involvement,” as told by insiders

THIS series is getting very long. We’ve got plenty to show. We have more issues to tackle, including ones we’ve not yet alluded to, and there have already been enough parts to justify a dedicated wiki/landing page (screenshot at the bottom of this post). It’s getting a lot longer than we originally envisioned or estimated; see our introduction, interlude, Part I, Part II, Part III, Part IV, Part V, Part VI, Part VII, Part VIII, Part IX, and Part X as many people are seeing them this month (it seems like people discover the series and tell colleagues about it).

“As it stands, Intel seems to love Microsoft more than it loves its own autonomy.”Non Proprietary Process required,” we’re told by one reader/viewer who experienced what we’ve been covering, “but [DX/nontechnical] team requested Google Docs…”

Sometimes (a lot more often than this) they request all sorts of Microsoft things. We’ll come to this later in the series. The latest video focuses on accountability and how Intel is basically assessing its own work instead of relying on an independent party. Moreover, just like at the Linux Foundation, totally non-technical people (or people who are technical in unrelated and irrelevant disciplines) make the important decisions and alienate technical people. Their objectives are inherently different and the products they cover or speak about they’ve never even used themselves (like a tons of Linux Foundation staff that never actually tried GNU/Linux… it’s just a brand to these people).

Get well soon, Intel. Or else… developers will tell you to get the hell out. Talent retention isn’t possible with patronising attitudes, mixed messages, and mere pretenses of “love”. As it stands, Intel seems to love Microsoft more than it loves its own autonomy.

The above speaks of “GNU Linux Developer Experience” and it’s not some jockeying or messing about. As a matter of fact, we’re being told on the record, this “was an approved internal document,” which was carefully prepared and then issued/passed on “due to issues with low/non-tech involvement with GNU Linux documentation.”

Again, this isn’t informal. This isn’t an infraction. “The document was released to appropriate business units,” we’re told.

Intel leaks

01.10.21

InteLeaks – Part X: Replacing Free Software With Microsoft, Turning One-Minute Processes Into Days Long

Posted in GNU/Linux, Hardware at 12:36 pm by Dr. Roy Schestowitz

Video download link

Summary: Processes that were entirely Free software-centric were rejected and replaced by truly antithetical spyware of companies that aren’t Intel and give Intel no autonomy or self-determination

MANY of us have had the experience or the displeasure of having to interact with if not use appalling tools which are neither needed nor desirable, usually because those are imposed by somebody else. That does not have to be imposed by a boss; sometimes it’s a peer.

“The developers aren’t happy. They don’t truly feel productive.”Intel is alienating its very own developers. Intel is recruiting the wrong people and it is partnering with the wrong companies. We’ve already discussed a great deal of material in the introduction, interlude, Part I, Part II, Part III, Part IV, Part V, Part VI, Part VII, Part VIII, and Part IX.

In Part IV we’ve already shown this part:

intel3

So, as one can see, developers who are meant to work on technical projects that are as distanced as can be from Microsoft are somehow compelled to deal with horrible things, even though perfectly fine Free software- and standards-based tools already exist and are already in place (at Intel).

“I do have firsthand experience with people refusing to use a changed/new process,” somebody told us. “However, I was surprised to experience the resistance of using Free and Open Source Software – by developers working on GNU Linux Projects.”

“Understanding the learning curve may have been a challenge for some,” we were informed, but “the engineer refusal was unexpected.”

It’s true that not everyone at Intel loved the workflow, but we’re told that the technical people — i.e. those doing all the work which matters — did like it and those who did not were in the minority (putting aside “DX”).

A person familiar with Intel (from the inside) said s/he would not comment on “Intel’s use of proprietary Microsoft formats, but it’s standard practice at companies that are partnered with Microsoft and have the company’s technologies deeply embedded in their desktop infrastructure, which again hints at the fact that Intel doesn’t really support free software but rather tolerates it to prevent other semiconductor companies from taking up a prominent role in the free software world [and] as for vapourware we only have to look at Itanium and Larrabee derived architectures such as the Knights Landing/Mill add-in cards, which were total failures in the marketplace, but because it’s Intel people pay attention to them — and worse waste precious time developing for/with them when they really shouldn’t…”

Just a day ago Michael Larabel wrote about Intel’s VPU work which targets Linux. “This Intel Vision Processing Unit enablement has now ballooned to nearly 22 thousand lines of code,” he wrote, “on top of all the existing Keem Bay SoC support upstreamed, compared to the 15 thousand lines for the VPU code in December.”

Our series shows a lot of what’s really going on in this department. The developers aren’t happy. They don’t truly feel productive.

« Previous entries Next Page » Next Page »

RSS 64x64RSS Feed: subscribe to the RSS feed for regular updates

Home iconSite Wiki: You can improve this site by helping the extension of the site's content

Home iconSite Home: Background about the site and some key features in the front page

Chat iconIRC Channels: Come and chat with us in real time

New to This Site? Here Are Some Introductory Resources

No

Mono

ODF

Samba logo






We support

End software patents

GPLv3

GNU project

BLAG

EFF bloggers

Comcast is Blocktastic? SavetheInternet.com



Recent Posts