We really think your technology is great. Your graphics are excellent. Your scalable-terrain engine knocked our socks off. Your physics engine is amazing. Your AI code is already quite remarkable. Your simulation of a believable, detailed fantasy world is outstanding.
But Lionhead, we have a problem.
Black and White just wasn't fun to play.
Once we were done being amazed at all the features and gasping at the technology - the game just wasn't very good. It didn't engage. We weren't motivated to continue. It just got boring. Sorry - no-one wanted it to be great more than us, but in the final analysis it just wasn't.
You guys are great. You plainly love what you do, and create high-quality product. We're grateful for your dedication. But please - make the next game fun first, then add in the AI, the nice graphics, the believable simulation. We appreciate that fun is hard to describe, hard to measure, hard to design or schedule or test. But it's important. It's only fun that separates a game from a fishtank.
Thanks for listening. Earth out.
getting high pagerank - easy if you're _relevant_
on
Mr Anti-Google
·
· Score: 1
If he's sensible, honest and has limited aspirations, then it's quite possible for "the little guy" to get a very high pagerank on google very quickly. Here's my success story:)
I bought a new PC game very soon after its release. As I'm not whoring for more pagerank or traffic, let's call it "back to fortress frankenstein" (BtFF). BtFF contains secrets areas, and I was surprised to discover that no website existed (in the google universe) that covered this topic. So, as I played through the game, I kept an ongoing "secrets of BtFF" page. Once it was reasonably mature, I mailed its URL to the few websites that were relevant (about five) Some linked to it, some didn't. I've done _zero_ "marketing" of the page since.
Only a few days after this the page started to show up as the top ranked site for google query "BtFF secrets". It stayed that way for months - even now (nine months later) it's still number two. So, for this very specific topic, it beats out all but one of the BtFF specific "portal" sites, fansites, etc.
So, I think this shows that google's pagerank is _supremely_ democratic, providing:
Your page is focussed - it only addresses a single topic. The narrower, the better.
Your page is "honest" - no redirects, dynamic content, logins - stuff that annoys users and thwarts search engines.
Your page is simple - no elaborate structure through which users and search engines have to go - plainly both will quickly give up if faced with too much complexity.
So, Salon's whiny guy is complaining that his page isn't ranked relevant, but then he breaks at least two of the simple rules, above, namely that his site is diffuse rather than focussed, and its structure is deep too. As previous posters said, boo hoo.
Well, I have an ancient Rio PMP 300. This hasn't been made for ages, so I'm not recommending it, but my experiences running with it might be of some interest to you.
1. _any_ spinning-media player is unsuitable for running, period.
2. surprisingly, even solid-state players aren't immune from shock related problems - bump the PMP300 in the right direction and the battery loses contact for enough time to reset the unit. Those players (the panasonic, the rio/nike units) that mount on the arm rather than the waist will survive this better (I think also that the 300 isn't very well designed in this regard). Also, check the earphone jack - I know some people who had crackling problems on (newer) rios due to dry solder connections on the earphone socket.
3. you don't need high-bitrate mp3s - 64kbps is fine for everything, given the vastly suboptimal listening contitions (traffic noise, one's own breathing sound, windnoise etc.) you'll experience on your run. For some stuff, 32kbps is quite acceptable. Downsampling your mp3 collection before uploading to the player thus greatly increases your music-milage.
4. if you're planning on using it as "soundtrack" to some event, for God's sake plan on using only one set of media - I've seen some dude try to change smartmedia cards on his player midway through a triathlon (on the bike section). Not pretty. Check your player's specs carefully - lots of players can only use media up to a certain size - often less than is now available.
I have a suplementary question - rather than buying one WAP per region (floor, wing, etc.), is it possible to reduce the number of WAPs by plugging multiple antennae into one WAP, perhaps with something as simple as a Y connector ?
This way someone rigging up a large or complex structure, but with relatively few stations, could have an antenna in each region, and string coax back to the WAP.
I know this will cause nasty phase-shift and multipath problems, due to the same station being received by both antennae, but 801.11 must already contend with this, as reflection from metal surfaces will cause it, even for the single-WAP-single-station case.
I'm just curious to see if someone has already tried something like this and failed, or if there's a good theoretical reason why it's a dumb thing to do.
THanks FIn
Who the hell CARES?
on
Tool Box PC
·
· Score: 0, Flamebait
Jeez, another slashdot story about COMPUTER CASES, surely the dullest topic possible.
If we're not being subjected to intriguing tales of small-footprint Intel boxes (yawn), it's yet another lateral-thinking genius who's fitted a beowulf cluster up a rhino's arse.
Yes, we get it. Computers are indeed small. Move along. Move along.
Everyone I know who has done so has, to a man, come back to me and said "It's amazing - you don't know what you're missing!"
Yep, that's right, I don't know what I'm missing. I know my NeverTwicetheSameColor TV sucks, but I'm not sure just how bad. If I find
out, it's liable to be an expensive revelation.
I wonder if McAfee's legal and technical folks
have gotten together get to think about what this
actually means.
It's likely (if not certain) that some enterprising hacker will figure out how McAfee
allows ML to slip under the radar, and will code
an exploit of their own to do the same.
Now, if someone buys AV software and it lets a
virus slip through, the shrinkwrap licence
probably protects the AV vendor from civil
suit - but if the vendor willfully put a
hole in then a court might well find that the
AV vendor acted in bad faith, which opens the
door to large punitive judgements.
McAfee would be covered if the Feds had compelled
them do to this, but given that they're
volunteering then that doesn't apply.
Of course, it isn't going to be you or I suing
them, but when Bluechip Inc. loses millions
from an attack of "Tragic Lantern" or whatever,
going after McAfee for actual and punitive
damages will, I suspect, sound pretty compelling.
There's lots of advantages for a satellite being small (and thus having a low mass):
Lower launch cost.
Rocket cost proceeds geometrically as payload size increases only linearly, so big satellites
are much more expensive to launch than are smaller ones.
Build a satellite small enough, then there's
a real chance it can be put into orbit by an
ambitious amateur rocket.
Cheaper makes for cheaper still
If a satellite is cheaper (by which I mean total cost = system cost + launch cost) then you're
more able to throw it away and replace it. The
more inclined you are to throw it away, the less
you worry about its maintaining an orbit - in the
extreme case you don't build in any altitude maintainance and only gyroscopic attitute maintainance - then you don't need orbital
control jets (and fuel, and all the associated
systems) - so your satellite becomes cheaper and
cheaper yet. So the satellite size reduces and
reduces until its stopped by another parameter
(e.g. mass of electronics, transponders etc.)
which doesn't shrink in this way.
Smaller is simpler is more reliable
As we said, smaller satellites don't need as
much (or any) orbital maintainance equipment.
That's one of the parts of a satellite that's
most likely to fail (and thus leave the satellite
useless because its pointing the wrong way). If
you can get the platform + payload cost down
far enough, it'll be cheaper (and more reliable)
to launch 10 cheap sats than one delux biggie.
It's much cheaper to scale up on the ground
Sure, making a small satellite makes for poorer
signal strength, but ground-based equipment (dishes, antennae, amps etc.) scale with a
much flatter geometric curve than do the same
improvements in orbit (when you've spent all
that money shoving them up the gravity well).
If the VLA can detect "a cellphone at Saturn",
a bigger dish here can detect a cokecan in LEO.
The current satellite design philosphy is largely
to engineer from a reliability-first perspective,
which is guaranteed to produce an expensive
solution. If satellites were built by
consumer-technology companies (Sony, Philips,
Dell, VolksWagen) they'd be cost-engineered
first (without reliability being at such a
premium) - and our solar system would soon have
another planet with a ring round it:)
It's essentially very like a UT "assault" map,
with an allied force storming up a beach into
an axis fortress. There are three alied
objectives.
Teamplay is like teamfortress classic -
both sides can have ammo-dudes and medic-dudes
(and there's no ammo or health packs in the
map at all).
Defenders (axis) can use fixed (infinite-ammo)
machine guns and can summon airstrikes. Allies
have to blast their way past barbed wire,
concrete walls and lots of angry Germans:)
Graphics are nice, shows its Quake3arena engine
roots a lot. Player graphics are good, but
it's hard to tell the two sides apart in the
heat of battle (deliberately, I'm sure).
Ammo is very limited, and damage-model is more
like counterstrike than Q3/UT (i.e. a couple of
hits to kill). I can't tell if there is
area-specific damage (headshots etc.).
I got pings of around 150 on my DSL connection,
but laggier (and less consistent) performance
than Q3 or UT with the same ping - I guess
that's why they're doing a network-only test:)
Really the only thing I didn't like much was
the respawning thing - that appears to be done
in waves - if you take a mortal wound (i.e. get
shot a lot) you have to wait 15 secs or so for
a friendly medic, who can bring you back. If you
miss that, you have to hang out 15-40 seconds
for the next "wave" of reenforcements, at which
time you respawn. That's a pretty good and
logical idea (it's frustrating enough to
discourage you from quake-style ramboism, but not
as final as counterstrike's way of things) but
it seems you have to "accept" your current
settings (character-class and main weapon) while
in that "limbo" state - I got messed up in the
menus there a couple of times and missed the
next wave, and so had to sit it out until the
next wave (which didn't seem so logical).
So, to summarise, looks pretty interesting for
a mere test version. Naturally, there's some
bugs to fix and some polishing to do for a
real game, but it certainly looks promising.
One word of warning to those of you with slower
connections - I'm not sure how worthwhile this
is for you to download, unless you feel very
motivated to help the developers - there isn't
that much life in the single map, so
you might get bored. Still, if the DSL
performance is sticky, I'd imagine the modem
performance is really sticky, and I'm sure the
developers will want lots of innocent modem
subjects for their twisted networking experiments.
RSMlabs is trying to sell RTlinux (strictly,
support for RTlinux) mainly to hardware and
CE companies, who would otherwise be using
something like pSoSystem, VxWorks, AMX, ThreadX,
or QNX.
Those companies have large, cautious legal
departments. They will not release product
that violates GPL, or that may in future be found
to do so - even if the voilation is by a
supplier or consultant. One activity that
lawyers do prior to signing an agreement with
compaies such as FSMlabs is a full due-dilligence
search for issues just such as this. FSM will have to answer some difficult questions
consequent to FSF's statement, regardless of how
much foundation it has.
This is something of a problem, in that
organising these people into a group or class
of litigants is difficult.
It's for this reason that FSF requests that
it be made assignee (or co-assignee) of copyright
on GPL/LGPLed code, so that it can be a party
of standing (i.e. that it can itself sue) in
court.
Never in court. It has, to date, never been necessary.
Although there is some doubt that some of the provisions of the licence are legally enforcable (particularly the "contagious" aspects thereof), counsel for most decent-sized companies are very paranoid about GPL, as the consequences of integrating GPLed code with proprietary stuff and then losing subsequently
in court would be quite severe. They plainly
think that GPL is sufficiently well drafted
that its enforcability is credible, and they're
not taking any chances.
In the last couple of years, management in
larger tech companies has recognised the PR
value of free/open code, and recognised also
how damaging being seen to violate GPL or
similar licences would be, so that's another
reason larger companies are careful not to
intentionally violate GPL.
I'd venture to suggest that the great majority
of cases where the GPL is broken are done through
ignorance, either that the code in question is
GPLed or ignorance of the implications of the
licence itself. I'd be willing to give the
RTLinux folks the benefit of the doubt, and say
that, while they have a different
interpretation of the GPL
fom FSF's, they're not acting in bad faith.
I've used two of the more popular NAT boxen on my home ADSL connection. For what it's worth, here's what I found:
Linksys BEFSR11
Easy to install, fast, very nice web-based control UI. I had significant ongoing problems with this unit, where it would get "blocked up" (where it would become largely unresponsive, even to pings). With sufficient perseverance once
could get through to the webUI and manually force
it to drop and reconnect its PPPoE connection, after which it was generally okay. There seemed to be a strong correlation between this happening
and my roommate using her (darn) win95 box. The
box also went similarly nutzo when the DSL
connection had occassional "issues" - when the
DSL was down, the box itself became mostly
unresponsive, even to internal traffic. I
have a two friends who also have this unit - one has perfect results, another has even worse
results (all, including myself, using the
latest Linksys firmware).
NetGear RP114
Doesn't have the same reliability issues that
the NetGear did. Its web interface is terrible,
but they do have an excellent telnet based
interface, which has a lot more real-time
technical info than did the Linksys' UI. Webpage
performance seems (subjectively) a bit more
sluggish, but raw DSL speed tests are still
nice and fast. Includes a DNS server, which the
Linksys didn't. Less non-techie friendly than
the linksys.
I never said it was Bush's fault. I said
"the U.S. government", which in the timescale
concerned is clearly the Clinton administration and the congresses contemporary with that
administration.
I have to say, I think the financial reason
for making this decision is quite a valid one -
it's certainly the President's task to protect
and foster U.S. industry, especially in
emerging fields such as this. The economic
interest issue plainly wasn't lost on the
President, but appears to have been so in the
subsequent discussions.
This is potentially the point at which Dima's best interests diverge from those of the anti-DMCA movement.
It's very possible that he'll cop a plea to
some reduced charge with a plea-bargained
penalty of time-served and a swift departure
from the U.S. Frankly, in his position, I'd
take that offer in a St.Petersburg minute and
bugger off home to see the wife and kids.
This is also an attractive scenario for the
Feds - they avoid backing down, and this
nasty problem flies off out of their jurisdiction, and they can go back to chasing
Hannibal Lecter or whatever.
The anti-DMCA lobby really wants a nice test-case to argue, but this isn't it:
Dima isn't an activist and hasn't "volunteered" to be a test case. The 2600 folks and Dr Felten have (to some extent), and are both in much stronger positions to defend
themselves than is Skylarov.
This case is complicated greatly by the
international dimension and the jurisdictional
questions that arise.
Adobe's change of heart complicates matters - a judge could throw out the Feds' complaint because of this, without ruling on the
constitutionality of the DMCA or the Feds'
interpretation thereof.
If I may be foolish enough to offer a prediction - I think the Skylarov case will only serve to
muddy the DMCA waters further - it'll take the
case that examines the conduct of an American
citizen acting in America to clarify things.
Here's some technical background info on smartcards. I hope it's
of value to y'all.
Protocols
Smartcards (and their predecessors, "chipcards") implement ISO standard
7816. As a previous writer noted, above, this largly defines the
physical, mechanical, and electrical characteristics of the card. It
also defines the communications protcol used by a terminal when
communicating with a card.
There are two major catagories of card, each with its own characteristics
and generally its own communications method. These are:
chipcards
These use ISO7814 part 4 S=0 ("synchronous") mode communications. They're
essentially dumb memory devices, which are serially strobed synchronous
data (a bit like an i2C chip in your PC) by the terminal. They don't
rise to the level of "smart"cards - other than some very basic
(password) authentication, they're just dumb memory devices. Most
include a suicide mechanism, whereby they blow their own internal
fuse (and thus become permanently dead) if you send them too many
wrong passwords. Typically these are used for applications that store
and manage a few values - e.g. phonecards, loyalty tokens and
utility meter tokencards.
smartcards
These use ISO7416 part 4 T=0 (character asynchronous mode) and T=1
(block asynchronous mode) communications. They're real computer devices
in their own right, typically with either an 8051 or Hitachi H8 8-bit
microcontroller as a brain and a surprising amount of memory - several
Kbytes of RAM and up to 64Kbytes of flash or EEPROM storage - pretty
impressive for a chip that's 2x3mm, I think.
T=0 is a simple, half-duplex, master-clocked serial protocol - you could
_almost_ use a regular UART to talk to the card, except the card's
initial message (its ATR - Answer To Reset) is sent synchronously, and
the UARTS in regular PCs don't have a raw/USART mode that would allow them
to receive this correctly. The actual communication speed varies
between cards (the card tells the terminal how fast it can go in
its ATR), but its generally very slow, around 300baud max.
T=1 is just a simple packet format
layed on T=0. Both T=0 and T=1 are, IMHO, rather crappy protocols.
True smartcards aren't just dumb memory devices - they run actual
programs, and often have built in special functions, generally
cryptography stuff (GemPlus makes DES and RSA enabled cards).
Major players
The leader in this space is undoubtedly GEMplus inc. of Lyon in
France, a company founded by the inventors of the chipcard.
I believe Hitachi itself also makes cards. When you get a card
from an institution (from DeLaRue, Visa, AMEX etc.) it's probably
come either from Hitachi or GEMplus.
GSM cellphone manufacturers and wireless service-providers. The
little ID chip in a GSM phone is just a regular smartcard chip,
same contacts and everything. On better phones it's customer-swappable
(so you could have a plan in the U.K., one in France and an Italian
prepaid card - you'd just use the appropriate one depending on
which country you're in - hence no roaming). The GSM folks
are particulaly excited about the future of smartcards - they
want to add new (non telephony apps) to the cards, so they can
be used for stuff like purchases, gambling, etc.
Somewhat surprisingly, Sun Microsystems is doing very well in
getting its JavaCard technology adopted for most real smartcard
deployments - most GEMplus cards, most recent GSM chips, and
both AMEX(blue) and VISA cards feature this super-reduced
java runtime environment. Application developers like this,
mostly because coding for the individual chips themselves
is as crufty as hell.
The physical connector to the smartcard (in the terminal) is
most often made by Amphenol. The little microcontroller that
talks T=0/1 to the card is generally from GEMplus, Hitachi or
Philips.
Security
As a replacement technology for regular magnetic swipe cards,
smartcards are _much_ more secure, mostly because magnetic
swipe cards are totally insecure - you can write one yourself
with a reader you paid a few hundred dollars for - there's no
magic and no cryptography at all.
As real security devices, smartcards aren't terribly
secure. They're designed to be tamper-proof, but their
form-factor ensures that this will never be very effective.
Current implementations leak information from various
sidechannels (EMF, heat-dissipation, elapsed-time to perform
crypto operations), some of which are pretty easily fixed and
some of which aren't. They're never going to be super
secure (you're never going to put the launch codes for
nuclear missiles on one), but they're probably fine for
real-world use for their current and proposed applications.
Writing code yourself
GEMplus sells (for a pretty reasonable price) an evaluation
kit with a few demo cards, some programming info and a
card interface that plugs into your PC's serial port.
You can get limited JavaCard stuff from java.sun.com,
but you typically need more stuff that pertains to
the specific card - you get this from the card's
manufacturer. The JDK's javac compiler is
used to compile code for the javacard.
Sun also has (or at least used to) a pretty comprehensive
software framework for the terminal (PC/server) end
of the equation - it's called OpenCardFramework. It
simplifies a lot of the pain-in-the-ass features
terminal programmers have to put up with when talking
to smartcards.
Privacy concerns
When used as a replacement for existing magnetic cards,
there's no more privacy concern than with the magnetic
cards - the credit card company knows all about all your
transactions either way, and with the smartcard you're
less likely to find out that some enterprising folks in
the Far East have cloned your card and tried to buy an
airplane with it.
There are privacy concens when you consider that the
card can host multiple applications. In practice, you
as a consumer (note: consumer is the new word for citizen,
apparently) have little to no knowledge of what is being
stored, run, or communicated to/from your card. The
card's crypto means you can't just open the card up
yourself and hunt around to see, so you'll have to
trust the issuer of the card (and their agents, etc.).
I rather enjoyed W's speech on this matter, where he weighed the
value of the potential benefits of
stem-cell research against the "moral hazards"
presented by their use. The President, however, neglected to mention a third
consideration - one I think was the tie-breaker,
and one that might go some way to explaining
the inconsistency in his moral position - money.
The U.S. has already fallen some years behind
Europe, and particularly the U.K., in a number of
biotechnology avenues. This isn't because of
some technical deficiency, but because of the
U.S. government's extreme sluggishness in
coming to concrete policy decisions on these
matters. In contrast, many other countries
(the U.K. in particular) took a very proactive
stance, and had decided what was and what
wasn't permissable in advance of the technical
wherewithall becoming available.
President Bush received an enormous amount of
lobbying from biotech concerns in the runup to
his making this decision, who felt that Europe's
biotech lead would only increase if federal
funding for stem-cell research wasn't forthcoming.
Thus this decision makes perfect sense - his primary motivation (as in so many of this other
decisions) is the financial interests of
the business concerns with which the President
is so closely allied.
The FDA's reservations with regard to Xenotransplantation (that is, the transplantation into humans of tissue or organs from other species) are, I think, very prudent.
The great majority of diseases that presently afflict human populations were (or, in many cases, continue to be) transmitted from both domestic and wild animals (nasties like influenza, HIV, ebola, and CJD included).
By their very nature, animals suitable for xenotransplantation are sufficiently close to humans for this transmission to be a very real
risk, and direct transplantation afforts a
hugely lower barrier to transmission than do
the current (already viable) means (ingestion,
animal bites, intermediate vectors, inhalation of
aerosolized organisms, etc.)
This isn't to say that xenotransplantation
shouldn't be done, only that great study and care
is necessary for it to be performed safely.
Not every caution or limitation on the progress of science arises from reactionary luddism or religious zeal.
>Would you be surprised if Intels compiler
>produced faster code than GCC?
Not really. As the GCC folks readily admit,
GCC is presently suboptimal at generating code
for highly superscalar instruction sets. This
isn't too much of a problem for P1->P4 (but gets
progressivly stickier) which aren't very rich
in that regard, but it gets to be a significant
issue for LIW and VLIW architectures (including
IA64).
This isn't a bad reflection on GCC or its
developers, however - writing such a compiler
(in particular, an instruction scheduler that
keeps the various pipelines efficiently filled)
is very hard, and this hitherto hasn't
been an issue for the mainstream architectures
at which GCC is targeted.
I remember reading somewhere that Philips spent
more writing the compiler for its TriMedia
VLIW chip (which is 5x5, as I recall) than they
did actually designing the chip itself.
It's an heretical suggestion, but maybe you should actually try the manager's job ?
Neglecting the conspiracy theories above (you should know by now if they're at all credible), this offer of a promotion really is a compliment - it means that you're well-respected within your company, and people think you could be taking a more challenging role.
You've probably never thought of yourself as "the management type" - I suspect this is because:
You've never had a really good manager - so you think "the management type" means "the stupids". This is often the case, but needn't be so - you have the chance to show it isn't.
You've never had ambitions in that direction. I'm very suspicious of anyone who does harbour a deep desire to be management. Lots of good managers didn't see that as their career paths, but (when the time came) they stepped up to bat
You're concerned that it'll be hard. You're right, it will be. You'll study, and practice, and with time you'll get good at it. Nothing worth doing was ever any other way.
To address you're specific concerns:
That the job is too political - this is because your previous manager(s) were
idiots! A good manager builds
concensus and gets buy-in from others.
That largely consists of just sitting down
talking to people. That your previous
management spent their time arguing with
other parts of the company only shows
that they hadn't done their jobs. Too
many managers think their job is to
"manage down" to their reports - when in
fact it's largely managing up (to their
bosses) and sideways, to their peers in
other parts of the company.
That there's too much "flak" (a "blame culture") at that level. This is because your previous managers were cretins! They didn't manage
expectations (more "managing up"), they didn't
push for adequate resources, they accepted
impossible tasks or deadlines, they de-motivated
their employees and they failed to build the
necessary relationships within the company to
make them successful.
It's a real problem in the tech industry, and
in society in general, that knowlegable,
compitent and well-motivated people are
unwilling to take on the responsibility
of leadership. That's why companies are
too often run by morons, and why the world
is run by lawyers.
>If triple DES is more secure than DES, then is 10x DES more secure than 3DES, assuming you use different keys at each iteration?
Sure, but probably not by as much as one might imagine, as cryptographic algorithms can have unexpected algebraic properties that can act so as to confound security. We know that DES has just such a propertly - doubleDES (which should have a complexity of keylength112) is much weaker than expected, which is why triple-des is used instead.
Cryptographers tend to view even small defects in crypto-algorithms as real problems, as those defects might be manifestations of larger, as yet undiscovered, flaws. So, dectuple-DES is quite a bit more secure than single or triple-DES, but it might well not be worth the trouble.
Multiplying-up DES in particular is a (time) expensive business. DES was designed to be implemented in hardware, so even a single software DEScrypt is expensive, and thus compounding DES with itself makes for a very very slow cipher when implemented in software.
>Does the above extent to any crypto alg? Triple blowfish? Quintuple IDEA?
Yes, theoretically, and so does the suspiction/expectation of unforeen algebraic properties that make doing so suboptimal.
>What about plaintext -> 3DES -> blowfish -> serpent? Do I gain a lot/anything by doing this?
Complicated 'though this is, it has the advantage that there's lower liklihood of the weirdo-algebra problem described above. It is, however, severe overkill.
Still, using multi-cyphers or multi-iterations is a poor substitute for having a decent cipher to begin with. If you're concerned that your chosen cipher has too small a key, use a cipher with a bigger key. If you're concerned that your chosen cipher is algorithmically flawed, use a cipher over which you have more confidence, rather than simply combining it with itself or others.
Slashdot Mirror
Come in please.
We really think your technology is great. Your graphics are excellent. Your scalable-terrain engine knocked our socks off. Your physics engine is amazing. Your AI code is already quite remarkable. Your simulation of a believable, detailed fantasy world is outstanding.
But Lionhead, we have a problem.
Black and White just wasn't fun to play.
Once we were done being amazed at all the features and gasping at the technology - the game just wasn't very good. It didn't engage. We weren't motivated to continue. It just got boring. Sorry - no-one wanted it to be great more than us, but in the final analysis it just wasn't.
You guys are great. You plainly love what you do, and create high-quality product. We're grateful for your dedication. But please - make the next game fun first, then add in the AI, the nice graphics, the believable simulation. We appreciate that fun is hard to describe, hard to measure, hard to design or schedule or test. But it's important. It's only fun that separates a game from a fishtank.
Thanks for listening. Earth out.
I bought a new PC game very soon after its release. As I'm not whoring for more pagerank or traffic, let's call it "back to fortress frankenstein" (BtFF). BtFF contains secrets areas, and I was surprised to discover that no website existed (in the google universe) that covered this topic. So, as I played through the game, I kept an ongoing "secrets of BtFF" page. Once it was reasonably mature, I mailed its URL to the few websites that were relevant (about five) Some linked to it, some didn't. I've done _zero_ "marketing" of the page since.
Only a few days after this the page started to show up as the top ranked site for google query "BtFF secrets". It stayed that way for months - even now (nine months later) it's still number two. So, for this very specific topic, it beats out all but one of the BtFF specific "portal" sites, fansites, etc.
So, I think this shows that google's pagerank is _supremely_ democratic, providing:
So, Salon's whiny guy is complaining that his page isn't ranked relevant, but then he breaks at least two of the simple rules, above, namely that his site is diffuse rather than focussed, and its structure is deep too. As previous posters said, boo hoo.
Well, I have an ancient Rio PMP 300. This hasn't been made for ages, so I'm not recommending it, but my experiences running with it might be of some interest to you.
1. _any_ spinning-media player is unsuitable for running, period.
2. surprisingly, even solid-state players aren't immune from shock related problems - bump the PMP300 in the right direction and the battery loses contact for enough time to reset the unit. Those players (the panasonic, the rio/nike units) that mount on the arm rather than the waist will survive this better (I think also that the 300 isn't very well designed in this regard). Also, check the earphone jack - I know some people who had crackling problems on (newer) rios due to dry solder connections on the earphone socket.
3. you don't need high-bitrate mp3s - 64kbps is fine for everything, given the vastly suboptimal listening contitions (traffic noise, one's own breathing sound, windnoise etc.) you'll experience on your run. For some stuff, 32kbps is quite acceptable. Downsampling your mp3 collection before uploading to the player thus greatly increases your music-milage.
4. if you're planning on using it as "soundtrack" to some event, for God's sake plan on using only one set of media - I've seen some dude try to change smartmedia cards on his player midway through a triathlon (on the bike section). Not pretty. Check your player's specs carefully - lots of players can only use media up to a certain size - often less than is now available.
I have a suplementary question - rather than buying one WAP per region (floor, wing, etc.), is it possible to reduce the number of WAPs by plugging multiple antennae into one WAP, perhaps with something as simple as a Y connector ?
This way someone rigging up a large or complex structure, but with relatively few stations, could have an antenna in each region, and string
coax back to the WAP.
I know this will cause nasty phase-shift and multipath problems, due to the same station being received by both antennae, but 801.11 must already contend with this, as reflection from metal surfaces will cause it, even for the single-WAP-single-station case.
I'm just curious to see if someone has already tried something like this and failed, or if there's a good theoretical reason why it's a dumb thing to do.
THanks
FIn
Jeez, another slashdot story about COMPUTER CASES, surely the dullest topic possible.
If we're not being subjected to intriguing tales of small-footprint Intel boxes (yawn), it's yet another lateral-thinking genius who's fitted a beowulf cluster up a rhino's arse.
Yes, we get it. Computers are indeed small. Move along. Move along.
The /. headline is (as usual) crap.
It's not a minicomputer (VAX, AS/400 etc.), it's a "mini-pc" - a PC in a small box.
I'm scared to look at an HTDV.
Everyone I know who has done so has, to a man, come back to me and said "It's amazing - you don't know what you're missing!"
Yep, that's right, I don't know what I'm missing. I know my NeverTwicetheSameColor TV sucks, but I'm not sure just how bad. If I find
out, it's liable to be an expensive revelation.
Ignorance is bliss
It's likely (if not certain) that some enterprising hacker will figure out how McAfee allows ML to slip under the radar, and will code an exploit of their own to do the same.
Now, if someone buys AV software and it lets a virus slip through, the shrinkwrap licence probably protects the AV vendor from civil suit - but if the vendor willfully put a hole in then a court might well find that the AV vendor acted in bad faith, which opens the door to large punitive judgements.
McAfee would be covered if the Feds had compelled them do to this, but given that they're volunteering then that doesn't apply.
Of course, it isn't going to be you or I suing them, but when Bluechip Inc. loses millions from an attack of "Tragic Lantern" or whatever, going after McAfee for actual and punitive damages will, I suspect, sound pretty compelling.
More soon.
FIn
Hey, I'm constantly receiving spam calls, who
want to talk to a "Mr A.Coward" - now I know
why, you bastard.
-
Lower launch cost.
-
Cheaper makes for cheaper still
-
Smaller is simpler is more reliable
-
It's much cheaper to scale up on the ground
The current satellite design philosphy is largely to engineer from a reliability-first perspective, which is guaranteed to produce an expensive solution. If satellites were built by consumer-technology companies (Sony, Philips, Dell, VolksWagen) they'd be cost-engineered first (without reliability being at such a premium) - and our solar system would soon have another planet with a ring round itRocket cost proceeds geometrically as payload size increases only linearly, so big satellites are much more expensive to launch than are smaller ones. Build a satellite small enough, then there's a real chance it can be put into orbit by an ambitious amateur rocket.
If a satellite is cheaper (by which I mean total cost = system cost + launch cost) then you're more able to throw it away and replace it. The more inclined you are to throw it away, the less you worry about its maintaining an orbit - in the extreme case you don't build in any altitude maintainance and only gyroscopic attitute maintainance - then you don't need orbital control jets (and fuel, and all the associated systems) - so your satellite becomes cheaper and cheaper yet. So the satellite size reduces and reduces until its stopped by another parameter (e.g. mass of electronics, transponders etc.) which doesn't shrink in this way.
As we said, smaller satellites don't need as much (or any) orbital maintainance equipment. That's one of the parts of a satellite that's most likely to fail (and thus leave the satellite useless because its pointing the wrong way). If you can get the platform + payload cost down far enough, it'll be cheaper (and more reliable) to launch 10 cheap sats than one delux biggie.
Sure, making a small satellite makes for poorer signal strength, but ground-based equipment (dishes, antennae, amps etc.) scale with a much flatter geometric curve than do the same improvements in orbit (when you've spent all that money shoving them up the gravity well). If the VLA can detect "a cellphone at Saturn", a bigger dish here can detect a cokecan in LEO.
Teamplay is like teamfortress classic - both sides can have ammo-dudes and medic-dudes (and there's no ammo or health packs in the map at all).
Defenders (axis) can use fixed (infinite-ammo) machine guns and can summon airstrikes. Allies have to blast their way past barbed wire, concrete walls and lots of angry Germans :)
Graphics are nice, shows its Quake3arena engine roots a lot. Player graphics are good, but it's hard to tell the two sides apart in the heat of battle (deliberately, I'm sure).
Ammo is very limited, and damage-model is more like counterstrike than Q3/UT (i.e. a couple of hits to kill). I can't tell if there is area-specific damage (headshots etc.).
I got pings of around 150 on my DSL connection, but laggier (and less consistent) performance than Q3 or UT with the same ping - I guess that's why they're doing a network-only test :)
Really the only thing I didn't like much was the respawning thing - that appears to be done in waves - if you take a mortal wound (i.e. get shot a lot) you have to wait 15 secs or so for a friendly medic, who can bring you back. If you miss that, you have to hang out 15-40 seconds for the next "wave" of reenforcements, at which time you respawn. That's a pretty good and logical idea (it's frustrating enough to discourage you from quake-style ramboism, but not as final as counterstrike's way of things) but it seems you have to "accept" your current settings (character-class and main weapon) while in that "limbo" state - I got messed up in the menus there a couple of times and missed the next wave, and so had to sit it out until the next wave (which didn't seem so logical).
So, to summarise, looks pretty interesting for a mere test version. Naturally, there's some bugs to fix and some polishing to do for a real game, but it certainly looks promising.
One word of warning to those of you with slower connections - I'm not sure how worthwhile this is for you to download, unless you feel very motivated to help the developers - there isn't that much life in the single map, so you might get bored. Still, if the DSL performance is sticky, I'd imagine the modem performance is really sticky, and I'm sure the developers will want lots of innocent modem subjects for their twisted networking experiments.
Those companies have large, cautious legal departments. They will not release product that violates GPL, or that may in future be found to do so - even if the voilation is by a supplier or consultant. One activity that lawyers do prior to signing an agreement with compaies such as FSMlabs is a full due-dilligence search for issues just such as this. FSM will have to answer some difficult questions consequent to FSF's statement, regardless of how much foundation it has.
It's for this reason that FSF requests that it be made assignee (or co-assignee) of copyright on GPL/LGPLed code, so that it can be a party of standing (i.e. that it can itself sue) in court.
Although there is some doubt that some of the provisions of the licence are legally enforcable (particularly the "contagious" aspects thereof), counsel for most decent-sized companies are very paranoid about GPL, as the consequences of integrating GPLed code with proprietary stuff and then losing subsequently in court would be quite severe. They plainly think that GPL is sufficiently well drafted that its enforcability is credible, and they're not taking any chances.
In the last couple of years, management in larger tech companies has recognised the PR value of free/open code, and recognised also how damaging being seen to violate GPL or similar licences would be, so that's another reason larger companies are careful not to intentionally violate GPL.
I'd venture to suggest that the great majority of cases where the GPL is broken are done through ignorance, either that the code in question is GPLed or ignorance of the implications of the licence itself. I'd be willing to give the RTLinux folks the benefit of the doubt, and say that, while they have a different interpretation of the GPL fom FSF's, they're not acting in bad faith.
Linksys BEFSR11 Easy to install, fast, very nice web-based control UI. I had significant ongoing problems with this unit, where it would get "blocked up" (where it would become largely unresponsive, even to pings). With sufficient perseverance once could get through to the webUI and manually force it to drop and reconnect its PPPoE connection, after which it was generally okay. There seemed to be a strong correlation between this happening and my roommate using her (darn) win95 box. The box also went similarly nutzo when the DSL connection had occassional "issues" - when the DSL was down, the box itself became mostly unresponsive, even to internal traffic. I have a two friends who also have this unit - one has perfect results, another has even worse results (all, including myself, using the latest Linksys firmware).
NetGear RP114
Doesn't have the same reliability issues that the NetGear did. Its web interface is terrible, but they do have an excellent telnet based interface, which has a lot more real-time technical info than did the Linksys' UI. Webpage performance seems (subjectively) a bit more sluggish, but raw DSL speed tests are still nice and fast. Includes a DNS server, which the Linksys didn't. Less non-techie friendly than the linksys.
Wow, cool. I'd love to see the code for that - do you know where I'd find it?
I have to say, I think the financial reason for making this decision is quite a valid one - it's certainly the President's task to protect and foster U.S. industry, especially in emerging fields such as this. The economic interest issue plainly wasn't lost on the President, but appears to have been so in the subsequent discussions.
It's very possible that he'll cop a plea to some reduced charge with a plea-bargained penalty of time-served and a swift departure from the U.S. Frankly, in his position, I'd take that offer in a St.Petersburg minute and bugger off home to see the wife and kids.
This is also an attractive scenario for the Feds - they avoid backing down, and this nasty problem flies off out of their jurisdiction, and they can go back to chasing Hannibal Lecter or whatever.
The anti-DMCA lobby really wants a nice test-case to argue, but this isn't it:
- Dima isn't an activist and hasn't "volunteered" to be a test case. The 2600 folks and Dr Felten have (to some extent), and are both in much stronger positions to defend
themselves than is Skylarov.
- This case is complicated greatly by the
international dimension and the jurisdictional
questions that arise.
- Adobe's change of heart complicates matters - a judge could throw out the Feds' complaint because of this, without ruling on the
constitutionality of the DMCA or the Feds'
interpretation thereof.
If I may be foolish enough to offer a prediction - I think the Skylarov case will only serve to muddy the DMCA waters further - it'll take the case that examines the conduct of an American citizen acting in America to clarify things.Protocols
Smartcards (and their predecessors, "chipcards") implement ISO standard 7816. As a previous writer noted, above, this largly defines the physical, mechanical, and electrical characteristics of the card. It also defines the communications protcol used by a terminal when communicating with a card.
There are two major catagories of card, each with its own characteristics and generally its own communications method. These are:
These use ISO7814 part 4 S=0 ("synchronous") mode communications. They're essentially dumb memory devices, which are serially strobed synchronous data (a bit like an i2C chip in your PC) by the terminal. They don't rise to the level of "smart"cards - other than some very basic (password) authentication, they're just dumb memory devices. Most include a suicide mechanism, whereby they blow their own internal fuse (and thus become permanently dead) if you send them too many wrong passwords. Typically these are used for applications that store and manage a few values - e.g. phonecards, loyalty tokens and utility meter tokencards.
These use ISO7416 part 4 T=0 (character asynchronous mode) and T=1 (block asynchronous mode) communications. They're real computer devices in their own right, typically with either an 8051 or Hitachi H8 8-bit microcontroller as a brain and a surprising amount of memory - several Kbytes of RAM and up to 64Kbytes of flash or EEPROM storage - pretty impressive for a chip that's 2x3mm, I think.
T=0 is a simple, half-duplex, master-clocked serial protocol - you could _almost_ use a regular UART to talk to the card, except the card's initial message (its ATR - Answer To Reset) is sent synchronously, and the UARTS in regular PCs don't have a raw/USART mode that would allow them to receive this correctly. The actual communication speed varies between cards (the card tells the terminal how fast it can go in its ATR), but its generally very slow, around 300baud max. T=1 is just a simple packet format layed on T=0. Both T=0 and T=1 are, IMHO, rather crappy protocols.
True smartcards aren't just dumb memory devices - they run actual programs, and often have built in special functions, generally cryptography stuff (GemPlus makes DES and RSA enabled cards).
Major players
Security
As a replacement technology for regular magnetic swipe cards, smartcards are _much_ more secure, mostly because magnetic swipe cards are totally insecure - you can write one yourself with a reader you paid a few hundred dollars for - there's no magic and no cryptography at all.
As real security devices, smartcards aren't terribly secure. They're designed to be tamper-proof, but their form-factor ensures that this will never be very effective. Current implementations leak information from various sidechannels (EMF, heat-dissipation, elapsed-time to perform crypto operations), some of which are pretty easily fixed and some of which aren't. They're never going to be super secure (you're never going to put the launch codes for nuclear missiles on one), but they're probably fine for real-world use for their current and proposed applications.
Writing code yourself
GEMplus sells (for a pretty reasonable price) an evaluation kit with a few demo cards, some programming info and a card interface that plugs into your PC's serial port.
You can get limited JavaCard stuff from java.sun.com, but you typically need more stuff that pertains to the specific card - you get this from the card's manufacturer. The JDK's javac compiler is used to compile code for the javacard.
Sun also has (or at least used to) a pretty comprehensive software framework for the terminal (PC/server) end of the equation - it's called OpenCardFramework. It simplifies a lot of the pain-in-the-ass features terminal programmers have to put up with when talking to smartcards.
Privacy concerns
When used as a replacement for existing magnetic cards, there's no more privacy concern than with the magnetic cards - the credit card company knows all about all your transactions either way, and with the smartcard you're less likely to find out that some enterprising folks in the Far East have cloned your card and tried to buy an airplane with it.
There are privacy concens when you consider that the card can host multiple applications. In practice, you as a consumer (note: consumer is the new word for citizen, apparently) have little to no knowledge of what is being stored, run, or communicated to/from your card. The card's crypto means you can't just open the card up yourself and hunt around to see, so you'll have to trust the issuer of the card (and their agents, etc.).
The U.S. has already fallen some years behind Europe, and particularly the U.K., in a number of biotechnology avenues. This isn't because of some technical deficiency, but because of the U.S. government's extreme sluggishness in coming to concrete policy decisions on these matters. In contrast, many other countries (the U.K. in particular) took a very proactive stance, and had decided what was and what wasn't permissable in advance of the technical wherewithall becoming available.
President Bush received an enormous amount of lobbying from biotech concerns in the runup to his making this decision, who felt that Europe's biotech lead would only increase if federal funding for stem-cell research wasn't forthcoming.
Thus this decision makes perfect sense - his primary motivation (as in so many of this other decisions) is the financial interests of the business concerns with which the President is so closely allied.
The great majority of diseases that presently afflict human populations were (or, in many cases, continue to be) transmitted from both domestic and wild animals (nasties like influenza, HIV, ebola, and CJD included).
By their very nature, animals suitable for xenotransplantation are sufficiently close to humans for this transmission to be a very real risk, and direct transplantation afforts a hugely lower barrier to transmission than do the current (already viable) means (ingestion, animal bites, intermediate vectors, inhalation of aerosolized organisms, etc.)
This isn't to say that xenotransplantation shouldn't be done, only that great study and care is necessary for it to be performed safely.
Not every caution or limitation on the progress of science arises from reactionary luddism or religious zeal.
Not really. As the GCC folks readily admit, GCC is presently suboptimal at generating code for highly superscalar instruction sets. This isn't too much of a problem for P1->P4 (but gets progressivly stickier) which aren't very rich in that regard, but it gets to be a significant issue for LIW and VLIW architectures (including IA64).
This isn't a bad reflection on GCC or its developers, however - writing such a compiler (in particular, an instruction scheduler that keeps the various pipelines efficiently filled) is very hard, and this hitherto hasn't been an issue for the mainstream architectures at which GCC is targeted.
I remember reading somewhere that Philips spent more writing the compiler for its TriMedia VLIW chip (which is 5x5, as I recall) than they did actually designing the chip itself.
Neglecting the conspiracy theories above (you should know by now if they're at all credible), this offer of a promotion really is a compliment - it means that you're well-respected within your company, and people think you could be taking a more challenging role.
You've probably never thought of yourself as "the management type" - I suspect this is because:
- You've never had a really good manager - so you think "the management type" means "the stupids". This is often the case, but needn't be so - you have the chance to show it isn't.
- You've never had ambitions in that direction. I'm very suspicious of anyone who does harbour a deep desire to be management. Lots of good managers didn't see that as their career paths, but (when the time came) they stepped up to bat
- You're concerned that it'll be hard. You're right, it will be. You'll study, and practice, and with time you'll get good at it. Nothing worth doing was ever any other way.
To address you're specific concerns:- That the job is too political - this is because your previous manager(s) were
idiots! A good manager builds
concensus and gets buy-in from others.
That largely consists of just sitting down
talking to people. That your previous
management spent their time arguing with
other parts of the company only shows
that they hadn't done their jobs. Too
many managers think their job is to
"manage down" to their reports - when in
fact it's largely managing up (to their
bosses) and sideways, to their peers in
other parts of the company.
-
That there's too much "flak" (a "blame culture") at that level. This is because your previous managers were cretins! They didn't manage
expectations (more "managing up"), they didn't
push for adequate resources, they accepted
impossible tasks or deadlines, they de-motivated
their employees and they failed to build the
necessary relationships within the company to
make them successful.
It's a real problem in the tech industry, and in society in general, that knowlegable, compitent and well-motivated people are unwilling to take on the responsibility of leadership. That's why companies are too often run by morons, and why the world is run by lawyers.Hacking people is more fun than hacking machines.
Sure, but probably not by as much as one might imagine, as cryptographic algorithms can have unexpected algebraic properties that can act so as to confound security. We know that DES has just such a propertly - doubleDES (which should have a complexity of keylength112) is much weaker than expected, which is why triple-des is used instead.
Cryptographers tend to view even small defects in crypto-algorithms as real problems, as those defects might be manifestations of larger, as yet undiscovered, flaws. So, dectuple-DES is quite a bit more secure than single or triple-DES, but it might well not be worth the trouble.
Multiplying-up DES in particular is a (time) expensive business. DES was designed to be implemented in hardware, so even a single software DEScrypt is expensive, and thus compounding DES with itself makes for a very very slow cipher when implemented in software.
>Does the above extent to any crypto alg? Triple blowfish? Quintuple IDEA?
Yes, theoretically, and so does the suspiction/expectation of unforeen algebraic properties that make doing so suboptimal.
>What about plaintext -> 3DES -> blowfish -> serpent? Do I gain a lot/anything by doing this?
Complicated 'though this is, it has the advantage that there's lower liklihood of the weirdo-algebra problem described above. It is, however, severe overkill.
Still, using multi-cyphers or multi-iterations is a poor substitute for having a decent cipher to begin with. If you're concerned that your chosen cipher has too small a key, use a cipher with a bigger key. If you're concerned that your chosen cipher is algorithmically flawed, use a cipher over which you have more confidence, rather than simply combining it with itself or others.