Become a fan of Slashdot on Facebook


Forgot your password?

Ubuntu 14.10 Released With Ambitious Name, But Small Changes 110

Posted by timothy
from the I'd-hoped-for-ubiquitous dept.
Ubuntu 14.10, dubbed Utopic Unicorn, has been released today (here are screenshots). PC World says that at first glance "isn't the most exciting update," with not so much as a new default wallpaper — but happily so: it's a stable update in a stable series, and most users will have no pressing need to update to the newest version. In the Ubuntu Next unstable series, though, there are big changes afoot: Along with Mir comes the next version of Ubuntu’s Unity desktop, Unity 8. Mir and the latest version of Unity are already used on Ubuntu Phone, so this is key for Ubuntu's goal of convergent computing — Ubuntu Phone and Ubuntu desktop will use the same display server and desktop shell. Ubuntu Phone is now stable and Ubuntu phones are arriving this year, so a lot of work has gone into this stuff recently. The road ahead looks bumpy however. Ubuntu needs to get graphics drivers supporting Mir properly. The task becomes more complicated when you consider that other Linux distributions — like Fedora — are switching to the Wayland display server instead of Mir. When Ubuntu Desktop Next becomes the standard desktop environment, the changes will be massive indeed. But for today, Utopic Unicorn is all about subtle improvements and slow, steady iteration.

Comment: Change is coming... (Score 2) 181

by luminousone11 (#47789659) Attached to: Intel's Haswell-E Desktop CPU Debuts With Eight Cores, DDR4 Memory
AMD, and IBM have both been talking about stacked designs for cache memory, Intel has been a big player in HBM/FCRAM development, and AMD, ARM, and others are throwing a lot of weight behind HSA, even Intel is bringing in some of the idea's of HSA at least as far as unified cpu/gpu virtual memory address spaces are concerned. The next 2-3 years is going to be transformative for computing, languages and software libraries will need to catch up with not just with macro threaded concurrency, but also with micro threading concepts. The convergence of "large enough" caches something like Iris Pro but with real cache memory instead of edram, HSA making igpu a first class citizen(think if opencl had access to the programs heap/stack, aka being able to call virtual functions, checking type information, accessing arbitrary objects not directly passed in the functions parameter list), and hopefully HBM/FCRAM will finely catch memory speed up at least for a year or 2(it'ill never last but here's hope'n lol).

Comment: It is a sin to destroy a working Commodore 64.... (Score 1) 212

Their are many pieces of the past that if works should not be destroyed, And even if they don't work, we can still very likely get parts off it. I personally would love to find an atari ST, atari falcon, Mac 128k, Amiga 600/1200, any of the atari 8 bit computers. It is a shame that so many of these fantastic pieces of hardware end up getting destroyed.

Comment: Re:x86 IS efficient (Score 5, Interesting) 168

by luminousone11 (#46098353) Attached to: AMD Announces First ARM Processor
1 byte?, you have no idea what you are talking about. AMD64 has a prefix byte before first op code byte, so in 64bit mode no instruction is smaller then 2bytes, Also 64bit arm is a new instruction set, and it does not in any way resemble 32bit arm. The fact is 64bit ARM, looks much more CISC'y then 32bit ARM, providing access to multiple address modes for load instructions, integrating the SIMD instructions rather then using costly co-processor extensions, having lightly variable length instructions, dedicated stack register and access instructions, And in a huge break from prior arm instruction sets they drop the conditional execution instructions from the instruction set. And it manages to increase the register count from 16 to 32 to boot as well. ARM has a bright future, It is not forced to waste huge swaths of transistors on decoding stupidly scatter brained instruction encodings built from 40 years of stacking shit on top of shit.

Comment: Typical of all bureaucracy's (Score 1) 345

by luminousone11 (#44248307) Attached to: The Pentagon's Seven Million Lines of Cobol
This is common to private industry as well, the only major difference being the scale of the project. The government needs to define a process that maintains the chain of custody of important software, and this should be redundant. If multiple persons or organizations are charged with this activity, it is less likely that a death or corporate bankruptcy(or simple lack of interest in continuing the contract) will create the situation where you have 7 million lines of code that nobody employed or contracted have any idea how the bollacks it works. I would suggest a few policy changes to improve the situation, 1. retain the right to directly hire or offer contract to any person employed by a contractor developing software if for any reason that contractor should cease being the contract. 2. when contracting or even writing software in house, on large projects(anything projected to have more then say a million lines of code), also hire a second development house to review and file bug reports on the software, submitting a patch history to both the primary developer and the software owner/government. 3. as relates to point 2, the second development house, as part of their contract an option to make them the primary developer in the event that the original developer can not fulfill the needs of the work, or cease being the developer for any reason.

Comment: Re:other factors (Score 1) 317

by luminousone11 (#43714673) Attached to: Did Internet Sales Tax Backers Bribe Congress? (Video)
In most States "teacher unions, firefighter unions, police unions, etc." are paid out of income taxes, property taxes and property taxes. Sales tax generally go into State general funds, and are used non-road infrastructure, road infrastructure, back funding of income tax cuts, Medicaid, and frivolous lawsuits over things like nullification of federal laws(albeit in Utah the States School land fund is used for this)

Google Developer Testifies That Java Memo Was Misinterpreted 201

Posted by timothy
from the not-what-I-meant dept.
benfrog writes with a piece that appeared in yesterday's Wall Street Journal about the in-progress legal battle between Oracle and Google over Java: "Ex-Sun and current Google employee Tim Lindholm testified that it was "not what he meant" when asked about the smoking gun email (included here (PDF)) that essentially said that Google needed to get a license for Java because all the alternatives 'suck[ed].' He went on in 'brief but tense testimony' to claim that his day-to-day involvement with Android was limited."

Comment: Re:Won't someone think of the children? (Score 2) 557

by luminousone11 (#39148583) Attached to: NYC To Release Teacher Evaluation Data Over Union Protests
Their are so many things that effect student performance outside of the classroom. The child's home conditions, parent involvement, etc. Yes testing can provide a certain measure of understanding, but using test scores exclusively or even as a large part of an overall evaluation of a teacher is incredibly flawed.

Teachers in my state at least(Utah) just are not paid enough in the first place(25-35k per year), if people want to implement merit pay based on some "report card" developed by a bunch of ideological extremists(like say the Utah Legislature) the end result isn't going to be pretty. All the tests will be designed to fail teachers and schools to push charter school rent seekers and likely used as an excuse to push privatization schemes.

Comment: Re:ARM suffers from the same problem all riscs do (Score 1) 140

by luminousone11 (#38912041) Attached to: AMD Says It's 'Ambidextrous,' Hints It May Offer ARM Chips its a mess, with 64bit we have a prefix byte , 1 to 4 bytes for the op, mod byte, and above that with avx we have the DREX byte, potentially imm byte. etc. I see no reason why intermediates can't occupy the space the next instruction would have and be aligned to the size of the fixed instruction length. that one exception to the fixed size rule shouldn't cause that much trouble for decoding of instructions.

Comment: ARM suffers from the same problem all riscs do (Score 1) 140

by luminousone11 (#38911183) Attached to: AMD Says It's 'Ambidextrous,' Hints It May Offer ARM Chips
ARM like any risc chip is great for a particular level of complexity, for a particular application, or situation.

Basically predictions of RISC eating x86 for breakfast were made over 15 years ago and never came to pass. Mostly by x86 morphing so that the difference was essentially irrelevant.

Exactly. x86 might be a pain to decode, but the fact that you can replace the backend arch that actually does all the work with one that fits the particular level of complication desired means that x86 unlike ARM(or any risc for that matter) can scale from simple 8086 with 29,000 transistors to that of a westmere-ex with 2,600,000,000 transistors. and go from 8bit to 64bits, or with SIMD 256bit. when they added large caches throw in instructions for cache control/hinting. What is really needed is a fixed instruction length CISC arch with an opcode address space large enough for future expansion, a means to deprecate old instructions, keep x86 addressing(the 64bit model that is), and an ISA that is designed to be easily decoded into whatever the chip is really running.

MS-DOS must die!