Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×

Comment What about Ammonia? (Score 1) 659

Not as sleek, awesome or expensive... but Ammonia fuel cells are getting pretty good these days. Ammonia is already produced across the planet as fertilizer by the ton. And it can be produced already using several processes from oil, natural gas, propane, biologicals and of course recycled sewage.

Ammonia has a higher energy density than hydrogen, is easier to store, and can be transported easily at 8-10 bars of pressure. Lastly, ammonia is the second most widely produced commodity chemical in the world.

Only downside, it's poisonous. On the upside, you can easily smell a leak at safe levels 1ppm. I think hydrogen would asphyxiate people if there was a slow leak, as it's odorless.

Comment Re:Aging workforce (Score 3, Interesting) 629

I disagree. Having worked in everything from multinational companies to 3 man start-up companies I think I've seen quite a bit of the dev world.

I think a well balanced team usually consists of older and younger developers myself.

What you want to avoid as a manager is encouraging cliques and age-based group stratums. Socially people will naturally tend to separate by age somewhat, but by spreading your experienced devs in with the less experienced you create new niches and groups that center around productive aspects such as projects, platforms, and responsibilities.

A few tricks I've used is allow developers to volunteer for project milestones. This gives you good cross-communication setup between project and age groups and allows devs to find their fit if you structure your projects right.

Another trick is to encourage creativity and social rewards. Having code meetings where the entire crowd gets to work through some code together. Each meeting, a different person or team brings part of their project to present and explain their design choices and algorithms for the rest of the team. The team gets to learn a bit, and also can positively (or occasionally negatively) critique the code and look for problems. This can work across projects and departments as well.

You need to encourage social activities across groups as well, but be careful not to cut into outside time too much. Older devs generally have lives outside of work. So limit your after-work socializing and instead encourage innovative activities with 15 minute coffee breaks together or an after-meeting walk.

If you're having problems motivating older developers then it's quite likely that you're not building, managing and deploying your experience properly. You need to do more than toss them in a cube with a set of project milestones. Younger people will do better in that environment if only because they will have more time to sacrifice.

Older people have already done their "lone wolf" time, and generally expect better management and organization. They expect resources to get the job done efficiently and want to be learning and mentoring, not just chugging out LOC. Most of them won't complain as devs tend to be introverts for the most part. If you want productive feedback then you need to empower groups with responsibilities beyond milestones. They need to have time to evaluate and analyze. They need to have time to go over designs and understand, give input, and have their input rewarded.

The secret is to create balanced work environments that allow your workers to be both productive and growing. Having static organizational structures that boxes devs into platforms and languages for years creates experience lags and power bubbles. Having work/slave relationships creates revolving doors. Having loose organizations creates deadline creep and project failure.

In the end, there are plenty of organizations successfully employing developers into retirement age. What you want is an organization that manages goals and expectations by delegating work to teams that are organized with mixed experience and socially rewarded for meeting deadlines. Management should be open to criticism and giving out criticism when necessary. Teams should as well.

Lastly, realize that most developers aren't strictly motivated by dollars. Most people are far more motivated to work towards a goal when the reward is linked with their goals and creativity. Developers need to have the room to try things and fail at them, refine and build on those experiences. If you build that into your development process then you will reduce product and project failures enormously.

Anyway, just my ramblings...

Comment Re:It won't fit (Score 2) 245

I think the article is complete bollocks, but simple basic DSP isn't that difficult if you use a simple codec. Hell, even a morse code type system with basic CRC checking wouldn't take more than 16k. It doesn't have to deal with echo (high frequency is rather directional), it doesn't have to deal with doppler (few moving objects), and it's obviously a secondary communications channel.

The thing that gives it away for me is that something could embed so deeply without being detected, as USB and networks are heavily scanned these days.

I have written plenty of kernel code, bios code and the like. The effort to get such perfect code running without causing crashes or being detected on the network would be enormous. If it's at all possible, it would certainly require government level funding.

I'm not saying it isn't possible - but it's just very, very unlikely.

Comment Re:Running key is dead... Long Live the One Time P (Score 1) 71

Use /dev/random and Monolith... dd from random into a file the same size as your cleartext, use Monolith to xor the files into a third file, secured file. The random file is essentially your key, so it must be kept separate from your secured file to be safe.

http://monolith.sourceforge.net/

Comment Re:I've been working on RSA for over ten years... (Score 1) 282

Thanks for that, I found it separately also, and read a few of the papers referenced. I tend to agree that this madness is a bit overblown. Reducing the time by 15% is really impressive overall, but when our anticipated sieving times for a typical 2k-4k keysize are measured in months and years that isn't a huge difference.

Comment Re:I've been working on RSA for over ten years... (Score 1) 282

Okay, here's the slides from a talk:
https://www.cryptolux.org/mediawiki-esc2013/images/c/cd/Joux-EM-multiuser-ESC2013.pdf

And a paper which is related:
http://eprint.iacr.org/2013/095.pdf

Basically, from my first read, this is just a better sieve, a system which should find smooth numbers faster by choosing better starting points and using faster tests. I wouldn't call it a general break in RSA, and while it might certainly be a better sieve than GNFS, it's no silver bullet either. I can't imagine anyone breaking RSA numbers like this unless they're very well funded.

Comment I've been working on RSA for over ten years... (Score 3, Interesting) 282

I'm surprised to see other people going in the direction I've been going for about 3 years now. Really. I thought I was quite alone in my path, LOL.

I need to read this paper still, but if it's taking the same path I did, then it's not a peachy as some think.

I'm only am amateur, so take this from the point of view as someone who kicks back with a beer and enjoys solving impossible computational problems.

I don't think it's that close to being broken... I think it'll take a huge computing effort (think multi-terabyte databases) to generate the tables across the PQ space required so that existing problems can be used to quickly find paths and intersections. At the beginning you're looking at only a VERY SMALL speedup from modern sieving, but once the tables get generated (years of effort) you'll eventually see faster and faster improvements. At least, that's with my algorithm, which I'm sure is far from perfect and only works on a certain set of primes right now. Which is about 20%. Which is far from optimal.

So yeah, progress. But I'm unconvinced that this will work for all primes.

I'm going to read the paper now... which I'm sure is far better than what I've been doing.

Comment Re:Cheaper Options.... (Score 1) 251

Not really... people all over the world buy cellphones and import them for a massive price hike all the time.

I really doubt that Canonical would advance a vaporware phone. They've got a huge interest in going mobile with Ubuntu Touch, and the hardware designs already exist. There's nothing new here other than a particular mix of existing tech and a contract manufacturer.

Going for a prestigious custom design to show off their software looks much better than the 50$ chinese knockoff that the carriers will likely fund.

Comment Re:Shuttleworth (Score 2) 251

Will the Ubuntu Edge be sustainable and/or hardware hackable?
While we will do our best to keep the hardware as open as possible, these are not the main focus of the project in its first generation. Hardware that’s capable of convergence is the priority.

What networks are supported?
The Ubuntu Edge is an unlocked device that works in all countries with GSM/3G/LTE network services. For GSM, which covers a lot of countries but not all operators, the Edge will support the 850, 900, 1800, 1900 and 2100 MHz frequencies. You can check support in your country here.

The Edge will support LTE standard frequencies and multi-band support for roaming. Yes, you can use the Edge on Verizon and Sprint.

So no locked bootloader, but you will likely have to live with binary blobs also (like 99% of phones out there).

Comment Re: You can't avoid piracy (Score 1) 298

Seriously - listen up to this.

You need to be posting videos, extra articles, guest articles and all things awesome online.

You need to talk up your online swag in your magazine and make it part of the experience. And you want it to be part of the total experience of owning the magazine. Indispensable in other words.

Slashdot Top Deals

Any circuit design must contain at least one part which is obsolete, two parts which are unobtainable, and three parts which are still under development.

Working...