Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror

Comment: Re:KDBus - another systemd brick on the wall (Score 1) 160

by fuzzyfuzzyfungus (#49560747) Attached to: Linux 4.1 Bringing Many Changes, But No KDBUS
Very true; though (on the whole) the end user has made the same choice when they'd either have to buy more hardware or spend more for software and/or make do with fewer features.

Even situations that are highly cost sensitive and have customers who bear the entire cost of the extra hardware or the extra software engineering (like embedded systems) have seen a fair amount of hardware growth. Cortex-M0 or a bunch of extra squeezing to get it into an 8 or 16 bit micro?

Comment: Re:KDBus - another systemd brick on the wall (Score 1) 160

by fuzzyfuzzyfungus (#49560681) Attached to: Linux 4.1 Bringing Many Changes, But No KDBUS
I'm no expert; but my off-the-cuff assumption would be that it could be made quite fast:

At least with Debian and derivatives, you have a locally stored cache of package data(not the packages themselves, but their metadata). Searching that is pretty fast unless you have a lot of repositories or a brutally slow storage system.

The obvious(and probably flawed in some less obvious way that I'm not thinking through) extension would be to add the VID/PID combinations (or device classes, for class drivers) to which a driver package applies to the existing metadata about the package. You might also have a 'driver package vs. 'non-driver package' distinction to reduce the search space). During the hotplug process, if nothing suitable is already available, apt-cache search for the VID/PID pair would be run, and a match downloaded, if available(the amount of security prompting would obviously be a matter of configuration: sometimes it would be desireable that admin authorization always be required, sometimes it would be better if downloads from already-blessed repositories are acceptable, depends on the use case).

The local search would be reasonably fast, barring very slow storage, the download and install obviously depending on the size of the driver and the speed of the connection. In the not-terribly-valuable opinion of a layman, it seems like it could be reasonably quick.

Comment: Re:AGP not working with SMP (Score 1) 160

by TheRaven64 (#49559459) Attached to: Linux 4.1 Bringing Many Changes, But No KDBUS

Multi-core x86 processors only appeared well after PCI-E had taken hold

True, but SMP systems are older. I used a dual P3-700 for years, which I picked up cheaply on eBay because not many people searched for 'duel processor' (I think eBay now does some phonetic matching in their search). Before that, the ABit BP6 (1999) was quite popular. It ran two Celerons, so you could get a dual-processor machine for cheaper than a single-processor one (though you needed to run Windows NT or *NIX to be able to use the second one, as XP was the first SMP-capable consumer OS from MS). The 300MHz Celerons overclocked to 450MHz by bumping the FSB from 66MHz to 100MHz, making it quite competitive with the P2 (the L2 cache in the Celeron was half the size, but twice the speed, and the core was the same).

Comment: Re:KDBus - another systemd brick on the wall (Score 2) 160

by fuzzyfuzzyfungus (#49558823) Attached to: Linux 4.1 Bringing Many Changes, But No KDBUS
This wouldn't be the kernel's problem; but it might be kind of neat to make the package manager aware of the hotplug process; in order to allow largely automated hunting of the repositories for the appropriate modules for a newly inserted device; but the amount of space saved may just not be enough to be worth the trouble. It'd arguably be more elegant than preloading more or less everything, or having the user grovel around with VID/PID combinations looking for helpful advice on Google; but storage tends to be cheaper than any human labor you'd want touching important software...

Comment: Re:edu-babble (Score 1) 283

by TheRaven64 (#49558665) Attached to: The Future Deconstruction of the K-12 Teacher
Really? Wikipedia tells me that kindergarten in the USA means up to age 6. By that time, I had been taught to read, write and do arithmetic (though I sucked at long division and found long multiplication hard until I was taught a third method a few years later). My handwriting is not much better now than it was then, though it did improve a bit in the middle as a teenager when I was writing on a regular basis.

Comment: Re:Z80 was in TRS-80 (Score 2) 107

by TheRaven64 (#49558639) Attached to: When Exxon Wanted To Be a Personal Computing Revolutionary

God I miss 80's computing.

I don't, but if you want to get the same fun without all of the old annoyances there are two things I'd recommend:

The first is to get an FPGA dev board. BlueSpec is a nice proprietary high-level HDL that is free for academic use, but if you don't qualify for that then CHISEL from Berkeley is also not bad - they're both a nice step above Verilog / VHDL.

The second is the mbed boards from various ARM partners. Some ARM folks handed me one of these to play with a few months back. These are aimed at getting embedded development to people who don't normally do it. They've got all of the fun I/O stuff from the BBC micro (plus some new stuff like USB and Ethernet) and a nicely put together development environment.

Comment: Re:Ah the Z-80 (Score 3, Insightful) 107

by TheRaven64 (#49558617) Attached to: When Exxon Wanted To Be a Personal Computing Revolutionary
They're increasingly hard to justify though. Cortex-M cores are really, really cheap (M0 and M0+ especially) and a modern 32-bit instruction set can be a significant win. You can't justify a 16-bit microcontroller on cost grounds anymore, let alone an 8-bit one. The main places Z80s are used is in systems designed in the early '80s that would cost too much to change, but which need periodic repairs.

I've seen a few things recently that have taken an amusing middle ground and bought ARM cores and used them to run a Z80 emulator, because it was cheaper to get the associated peripherals to attach to the ARM core.

Comment: Re:Google+ failed becuase it's GOOGLE (Score 1) 281

by TheRaven64 (#49558559) Attached to: Google Insiders Talk About Why Google+ Failed
I don't understand why Microsoft wants to go down that path. Their big money comes from businesses. They should be trumpeting private clouds (buy Windows server, install on a rack, run all of the cloudy stuff that you want under control of your company) and privacy to actively differentiate themselves from Google.

Comment: Re:Google Streams (Score 1) 281

by TheRaven64 (#49558545) Attached to: Google Insiders Talk About Why Google+ Failed
I've spent a depressing amount of the last couple of weeks looking at hotel web sites to find somewhere to stay for a business trip. About a year ago, almost all of them would have used Google Maps for their location page. Now about half used Bing Maps. I was quite surprised by this, though I vaguely remember Google starting to charge businesses for using GMaps (it could also be that Google highlights all of the competing hotels in the map, which probably isn't something that hotels want...). I didn't find the Bing map any worse than the Google one. Both were annoying in different ways.

Comment: Re:What we are seeing is ... (Score 5, Interesting) 281

by TheRaven64 (#49558537) Attached to: Google Insiders Talk About Why Google+ Failed

I expect Google to die in the same way that IBM died: it will still be a huge and influential player for a long time, but won't be the company that defines an industry that people care about. The same sort of path as Microsoft.

When I interviewed at Google a few years I was reminded of something that JWZ wrote about Netscape, claiming that it started to decline when it started hiring people who were there because it was a cool place to work, not because they wanted to change the world and believed in the things that the company was doing. Everyone I met at Google told me that I should would there because it was a cool place to work...

Comment: Re: Do not (Score 1) 125

by PopeRatzo (#49557337) Attached to: Liquid Mercury Found Under Mexican Pyramid

A bunch of workers hanging their body weight on the lever end would raise the stone a foot or two. You prop the stone with some timbers, shorten the lifting rope, and repeat. When the stone gets to the next level of the pyramid, you rotate the lever arm horizontally and pivot the stone to the next step.

Sounds plausible, except how does that lever get the stones to the top of a 455' structure? The widest "step" doesn't seem like it would allow room for enough guys to exert 800 lbs on a lever, much less for the lever itself. And we're talking a pretty long lever by the time you get halfway up. Then, you've got all the limestone sheathing to put up and you have to make sure the inside chambers are there, and accessible..

However they did it, it's pretty remarkable. I got to see it once up close and it's amazing.

Comment: Re: truly an inspiration. (Score 1) 425

If you repeat a lie long enough it will surely become reality. But, maybe, if you travel a little you will come to see the profound differences.

I've lived in 5 countries on 4 continents, 1st, 2nd and 3rd world.

Genetically, biologically, the differences are merely at the level of family resemblance and traits. The so-called 'races' are nothing more than HUGE extended families.

If a 6600 used paper tape instead of core memory, it would use up tape at about 30 miles/second. -- Grishman, Assembly Language Programming

Working...