cbmuser

59 ms·

661.
by cbmuser 6y ago
Sony uses multiple OEMs, including Sony EMCS in Japan and Foxconn in China. Usually, the first batches of a Sony product are made in Japan or the ones sold domestically. If you buy an early PlayStation 1, 2, 3 or 4 in Japan, they're us
662.
by cbmuser 6y ago
Not necessarily. All components can be made by Japanese companies. Whether Sony uses a Japanese supplier or a company from the other countries you mentioned is a matter of the production volume and which supplier makes the best offer.
663.
by cbmuser 6y ago
PlayStations are manufactured by different companies. Some are made by Sony EMCS, some by Foxconn and so on. Whether the PlayStation company let's them manufacture by one of Sony's own OEMs or a third party company is usually a ma
664.
by cbmuser 6y ago
As mentioned in another comment, you can get very fast m68k hardware with the Vampire accelerators these days which actually implement additional instructions and are therefore called 68080 by its developers.
665.
by cbmuser 6y ago
I have in fact an Amiga 4000/060 running Debian unstable as of now. There are new hardware accelerators being developed such as the Vampire which will provide a faster basis for running Linux on Amiga/m68k: > https:/&#x2F
666.
by cbmuser 6y ago
I have been a long-time Amiga user (since the 90s) and never let go of the machine - like many others in the community (we even have regular conferences and meetings etc with new hardware being developed and released). I personally became t
667.
by cbmuser 6y ago
Exactly. It's arch-specific code. It won't even show up in the kernel configuration unless the architecture is m68k.
668.
by cbmuser 6y ago
> Why is Macintosh II still being worked on but 386 support got killed? Because developers care about Motorola 68000, but no one cares about i386. No one wanted to step up to work on support for the original i386, so it got removed.
669.
by cbmuser 6y ago
I mean, it's not like the previous comment proved you otherwise by posting a link to the current kernel git tree. But ok.
670.
by cbmuser 6y ago
What's wrong with the kernel supporting a wide variety of hardware? As long as the stuff is actively maintained, I don't see a problem as this means it's actually being used. Linux always has had a very wide hardware support
671.
by cbmuser 6y ago
> Does the kernel ever remove support for devices or does this stuff just bloat up the codebase for eternity? As long as there is an active maintainer for the code, the code can stay forever and it's not really bloating up the kerne
672.
by cbmuser 6y ago
> Any people running Linux on some rare old hardware care to share why? It's called retro-computing and it's simply a hobby. You could also ask why people are fixing, maintaining and driving around with cars that are decades ol
673.
by cbmuser 6y ago
The m68k port is well maintained and is one of the oldest Linux ports of all. There are multiple active kernel maintainers and the port is regularly seeing improvements and new drivers such as for the X-Surf 100 ethernet card for the Amiga
674.
by cbmuser 6y ago
> there were no actual products announced. Correct me if I'm wrong, but I think they also didn't announce any actual hardware when they introduced Intel Macs. Interestingly, for the PowerPC->Intel transition, they also had a
675.
Bountysource reverts controversial change of ToS(github.com)
4 points by cbmuser 6y ago|0 comments
676.
by cbmuser 6y ago
That's really disappointing. I have four active campaigns which have collected already over $5000 in total, including the one Ian mentioned. I hope these issue can be resolved before the two years period expires. It would be a shame if
677.
by cbmuser 6y ago
> Like if building a pet app is your company/team's job then containers more than fine. If you're a distro maintainer that has thousands on thousands of packages then sharing libs starts to make a lot more sense. The probl
678.
by cbmuser 6y ago
The problem is that you need to keep track of all the binaries on your system which have embedded code copies.
679.
by cbmuser 6y ago
It would be great if the PowerPC-specific changes to Swift could be upstreamed so that Switft can be built on Debian's (and other BSD and Linux distributions) powerpc port.
680.
by cbmuser 6y ago
Germany has that, too. And probably every other country in the EU.
681.
by cbmuser 6y ago
In the electricity sector, yes. Not so much when it comes to process heat and district heating. Renewables still contribute less than 10% to the overall energy consumption in the US: > https://www.youtube.com/watch?v=31Bi
682.
by cbmuser 7y ago
I created a new organization, transferred the repository now and invited members. Worked like a charm.
683.
by cbmuser 7y ago
Out of curiosity. Did you use code from the linux-minidisc project? Would be great to see if our code was used in such innovative ways.
684.
by cbmuser 7y ago
Thanks. I'm already in contact with the owner of the fork with most of the fixes to figure out how we can merge all these changes into the upstream project. He has promised me to open PRs to get the changes merged upstream. I'm ha
685.
by cbmuser 7y ago
Great. Looking forward for new members. The project mailing list can be found here: > https://lists.fu-berlin.de/listinfo/linux-minidisc For archiving purposes, I recommend getting a Sony MZ-RH1 (and the MZ-RH200 II
686.
by cbmuser 7y ago
Edit: I have finally created a separate organization for the project now: https://github.com/linux-minidisc/linux-minidisc Original project creator and co-author of the linux-minidisc project here. Awesome to see my pr
687.
by cbmuser 7y ago
Why is there a sparc backend but no sparc64 backend? sparc64 is what Debian uses these days, so having support for it in Zig would be nice.
688.
by cbmuser 7y ago
I see, thanks. I know the NetBSD guys are still working on their sparc64 port.
689.
by cbmuser 7y ago
> As in you can compile Clang on sparc (using GCC / binutils as the system compiler), or as in you can actually build Debian for sparc64 using Clang? Initially, we were building Clang only. But we're also now building Clang usi
690.
by cbmuser 7y ago
> Sparc was deorbited as part of the GCC4.2.1 retirement effort — no one showed up to implement Sparc support in Clang, and the version of Sparc hardware FreeBSD ran on was extremely obsolete anyway. What's missing for sparc64 in Cl

More ›