Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Monday January 28 2019, @10:38PM   Printer-friendly
from the remember-when-browser-war-was-IE-vs-Netscape? dept.

Microsoft Engineer Causes Online Wrath After Saying Firefox Should Use Chromium

Mozilla should give up on its own browsing engine and switch Firefox to Chromium, a Microsoft engineer said in a series of tweets, as what the company does right now is "building a parallel universe that's used by less than 5 percent."

The message posted by Microsoft Product Manager Kenneth Auchenberg has triggered an almost instant reaction from the user community, with most of the replies pointing out that building alternative products that can compete against Chromium is vital for the health of the browsing ecosystem.

"It's time for @mozilla to get down from their philosophical ivory tower. The web is dominated by Chromium, if they really *cared* about the web they would be contributing instead of building a parallel universe that's used by less than 5%?" he tweeted.

"I couldn't disagree with you more. It precisely *because* Chromium has such a large marketshare that is vital for Mozilla (or anyone else) to battle for diversity. I'm shocked that you think they're not contributing. "Building a parallel universe"? That *is* the contribution," web developer Jeremy Keith responded.

[...] Auchenberg's message has obviously received more acid replies, including this one criticizing Microsoft's recent browser changes. "Just because your employer gave up on its own people and technology doesn't mean that others should follow," Asa Dotzler tweeted.

Also at ZDNet.

Previously: Microsoft Reportedly Building a Chromium-Based Web Browser to Replace Edge, and "Windows Lite" OS
Mozilla CEO Warns Microsoft's Switch to Chromium Will Give More Control of the Web to Google

Related: Is Google Using an "Embrace, Extend..." Strategy?
Google Denies Altering YouTube Code to Break Microsoft Edge


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2, Insightful) by Anonymous Coward on Tuesday January 29 2019, @02:17AM (2 children)

    by Anonymous Coward on Tuesday January 29 2019, @02:17AM (#793371)

    On the other hand, you never would have had things like Pixar animated movie, games like Overwatch, or indeed pretty much any software over the past 20 years including but not limited to the Internet as a whole.

    The same fragmentation which makes it "too hard and cost ineffective" to have viruses ALSO makes it "too hard and cost ineffective" to make complicated software.

    Let's not pretend that market consolidation had no benefits to it.

    Starting Score:    0  points
    Moderation   +2  
       Insightful=2, Total=2
    Extra 'Insightful' Modifier   0  

    Total Score:   2  
  • (Score: 2, Insightful) by ChrisMaple on Tuesday January 29 2019, @02:38AM (1 child)

    by ChrisMaple (6964) on Tuesday January 29 2019, @02:38AM (#793384)

    Compilers and system-specific standard libraries are why the same code runs on different hardware and different operating systems. Take a game or video rendering code and recompile it: mirabile dictu it runs on a different system.

    One of the reasons for not running interpreted languages is that it makes more types of systems vulnerable to a single piece of attack code.

    • (Score: 2) by Pino P on Tuesday January 29 2019, @04:43PM

      by Pino P (4721) on Tuesday January 29 2019, @04:43PM (#793611) Journal

      Altair kits, the Apple II, the Commodore Pet, Radio Shack TRS and the list goes on.

      Let the record state that these computers use 8-bit microprocessors in the 6502 and 8080 families. So do the Nintendo Entertainment System, Game Boy, Game Gear, ZX Spectrum, and MSX.

      Take a game or video rendering code and recompile it: mirabile dictu it runs on a different system.

      Albeit unplayably slowly. C compiled for 8-bit processors has slowdown compared to hand-coded assembly language for these processors. This is caused in large part by a mismatch between their machine model with that expected by the C language.

      C expects the processor to be able to load, add, and store 16-bit quantities quickly. This isn't true of 8-bit processors, which is why they're called 8-bit. Because all are promoted to int, and int must be at least 16 bits, an 8-bit processor has to add two int values by loading the least significant byte of both values, adding them, storing the result, loading the most significant byte of both values, adding them with carry, and storing the result.

      C expects processor registers to be wide enough to hold a pointer, which isn't true of the 6502. Instead, the 6502 has to store pointers on zero page. Where a C program would use an array of structs, a 6502 assembly program is more likely to use a structure of arrays, with different fields (and even different bytes of each field) in parallel arrays.

      Struct access in C and Pascal also expects the CPU's load and store instructions to be able to add a constant offset to a pointer, which isn't true of the 8080. Instead, 8080 has to explicitly add the offset to a struct's field, and keeping a pointer to one struct's base and a pointer to a field already hog four out of the CPU's seven 8-bit registers: base in DE and field in HL. If you're dealing with two structs, storing the base of one in BC and the base of the other in DE, you'll spill so many registers to RAM that you'll spend more time shuffling data in and out of registers than doing work. I trace this to the 8080's heritage as a refactor of the Intel 8008, a processor invented to run a reprogrammable dumb terminal, and dumb terminals rarely if ever deal with collections of structs. Zilog introduced new registers IX and IY on its 8080 clone specifically to hold struct base pointers, but that doesn't help users of Altair or Game Boy, whose processors lack IX and IY registers.

      It may turn out possible for a Sufficiently Smart Compilerâ„¢ to work around these deficiencies. But nobody in the 2010s appears to have enough money to improve cc65, SDCC, or other compilers that target 6502 or 8080 to be anywhere near competitive with assembly language. That's why I've written the 8-bit games in my GitHub account [github.com] in assembly language.

      Further reading about the difficulties of shoehorning C into 8080 family processors: