but when almost everyone uses it to mean what the original poster did, then "begging the question" has taken a new meaning
Except that we're thankfully not at that stage yet - this usage is common amongst North Americans (as are errors such as using "loose" when they mean "lose"), but is not widespread elsewhere.
What was it Kevin Mitnick said about social engineering?
I don't like butterscotch, but I do like vanilla. You don't see friggin holy wars over pudding, though, do you?
Bahahahahaha... Markoff is well known in Apple circles for panning Apple in his newspaper columns as being doomed a couple of years ago while simultaneously hawking his book on how Apple was, guess what, doomed.
This included such episodes as predicting Apple was about to be bought by Sun, Apple was going to move to x86, Apple was going to adopt Windows NT, Apple was going to sell off QuickTime, etc, etc. Oh, and a particularly peculiar episode where he started stalking Gil Amelio (then Apple CEO) and turning up unannounced at his house late at night.
He's always been completely clueless about anything vaguely Apple related, so why should I trust a word he says about any other subject? He's a cheap hack - I wouldn't trust him further than I could throw him.
The problem is not with software intended to run on a mac. the problem is with software intended to run on a linux machine. hence these are not "bugs" from the linux perspective.
"Linux" has nothing to do with it - if it supports Mac OS X as a target then it's a *nix program, and not something specific to Linux. Heck, if it wanted to run under the excuse for a POSIX subsystem on NT it would also fail since NTFS uses the same model as HFS+ (case-insensitive and case-preserving).
I think this problem could be handled best if either apple abandoned canse insentivity everywhere except possibly at the finder level.
Never going to happen - Apple chose the current behaviour for a reason, not on a whim.
Twirlip, how do we deal with the case insensitivity in UFS. it occasionally happens that a linux package will contain a directory with two files like "HEAD" and head or ReadME and readMe of "configure" and CONFIGURE.
Report this as a bug to the maintainer of the package - if they're at all interested in supporting Mac OS X as a Unix platform, they will have to remove the dependency on a case-sensitive volume format (aside from some ex-NeXT users, and fanboys who don't know any better, the Mac volume format is HFS+).
If you have to use some software which requires UFS, the best workaround is to create a large enough UFS disk image and install onto that - saves having to dedicate a whole partition to UFS, and handy for dumping onto DVD if you want to move the "UFS world" to another machine.
The QuickTime file format has always been documented - there have been QuickTime content generating apps available on multiple platforms forever (in a past life I wrote some code to emit QuickTime VR movies for a 3D toolkit on Irix).
The problem is always the codec used to encode the data - but if you've come up with a codec that doesn't infringe anyone's patents, why/how should they care? The problem is that to date, nobody in the OSS world has done so.
Re:Also at Macworld
on
Baked Apple
·
· Score: 2, Informative
That was Macworld 1998. He (Schiller) didn't actually throw it onto the floor, he jumped off a scaffold onto a bean bag while holding the iBook.
The demo was more about showing how AirPort kept working even if you shoogled it around, not really about bounce-testing an iBook^Wexecutive.
Sure it does - it stunk so badly, people on the east coast were diving out of theatres and calling ahead to pre-warn people in line out west. Not to mention Sat/Sun (assuming "weekend" includes Friday night) being down due to people reading reactions online from the previous night's viewings.
The truth of the matter is that it didn't have a lot of people rushing to theaters to go see it. It kind of fell off the radar with all the other movies out.
Nice theory, but then you'd expect it to pick up over time as people get round to viewing it. Which they patently haven't done.
As you hover the mouse across it, the shape of the bar distorts and icons scale up, sometime to take up a significant fraction of the entire display. The icons always look beautiful.
Yes, and it's all done with pixmaps - the largest style of icon applications can currently provide on Mac OS X is 128x128x32.
Larger icons may be more necessary over time (although display resolutions aren't increasing dramatically - it'll be a while before you get 5000x5000 on a consumer CRT/LCD), however Mac OS X manages quite well with 128x128. They undoubtably looked at using PDF for icons within Mac OS X as well, however the benefits are pretty marginal today.
So is the scaling algorithm more or less expensive than the SVG renderer?
On a desktop CPU, scaling a bitmap will probably be cheaper - either by using a vector unit like AltiVec, or by clever use of a GPU (like Mac OS X's Quartz Extreme - although that's really used for compositing rather than transformation at the moment).
What about CPUs with no hardware floating point (goes for both SVG and bitmap)?
I suspect bitmaps would be faster - scaling can be done with two lookup tables (one for each dimension), which are either pre-calculated with a real FPU or set up at run-time with fixed point.
What about scaling to print?
Yes, a vector image is more suitable for this case. But icons just aren't printed all that often - certainly not nearly so often as "pictures".
There's no hard and fast line between an icon and a picture, but icons have a fairly well defined role in current user interfaces: they're small pictograms displayed on screen (and even assuming monitor resolutions keep increasing, 128x128 or even 256x256 is going to be big enough for a while).
Of course, since SVG can contain both vector and pixmap data you could use it as a container for either form - depending on what you need it for. I suspect pixmaps would be more common however: the way most people generate icons on Mac OS X is to start with a photo or a screenshot, rather than working in Illustrator and rasterizing at the end (although, true, some people do that as well - their icons tend to look a bit over-Aquified though).
Same idea in Mac OS X - which calls them "badges". The API lets you composite one icon reference on top of another and draw it as a single entity (or to find out if an icon reference is actually a composite).
Personally I suspect there's not a great deal of point in making icons vector: 128x128x32 with a decent scaling algorithm (and an optional set of pre-scaled images at smaller sizes) seems to cover pretty much everything. At least for the tasks icons are typically used for. Anything larger than 128x128 is turning into a picture rather than an icon (yeah, you could use the same format for both, but why bother - 99% of the time an icon is just blitted to the screen or used for hit testing, both of which an 32-bit pixmap is ideal for).
1. Harrassing Aqua-ish theme makers. As Apple should know, you can't patent "look and feel" -- as their failed case against MS demonstrated.
The "harassment" was due to people copying and pasting widgets directly out of Mac OS X and passing them off as their own. And no, that's not what the failed "look and feel" case demonstrates - that case was lost due to the slack language Apple used in the contract they signed with MS. They gave MS more rights than they thought they had, and when they went to court this came out - hence they lost.
You most certainly can sue over "look and feel", due to a concept known as "trade dress". If I set up a MacDonalds fast food chain with a couple of golden-Ms, you can be I'd have a suit slapped on me within minutes.
Refusing to release a Sorenson codec enabled player or library for Linux, effectively locking Linux users out of an increasing majority of all Internet video content and thus making Linux unviable to end users
Mod -1, Boo Fucking Hoo. Apple signed a contract with Sorenson. Sorenson signed a contract with Apple. Those two companies entered into a deal whereby you're not going to get Sorenson's code for free on your platform. Get over it.
Instead of whining about it, why don't you get off your ass and write a better codec? What's that, it's hard? Well that's why people can and do build businesses around it...
3. Undercutting development of established Open Source projects, like Mozilla and XFree86, by pushing less open alternatives and thus both cutting their mindshare and draining developer talent.
Apple doesn't owe Mozilla anything - you've as much right to demand they use Mozilla as I've got to demand the Mozilla developers come over and paint my house. If an Open Source project can't stand on its own merits, why should it succeed?
And before someone replies 'but now it supports X11', the point is that they aren't the 'default' systems under MacOS -- which means "native" GUI MacOS X applications are useless to Linux
Yeah, and your average Gnome/KDE app won't run out of the box on a Mac either - your point is what? What Apple choses to make their default is their business - face it, X11 caters for a minority, and it's just not that useful to Apple's target market.
It's definitely a prudent move for Apple to ensure it runs reasonably well, since they want to see if they can expand their target market into the Unix workstation market (or what's left of it), but it's by no means their main focus.
In short: Apple is not Linux's friend, and these articles that claim otherwise are stupid and tiresome.
Apple is absolutely Linux's "friend" (in so far as a large company can be friends with a bunch of source files). For god's sake, it's Unix. On The Desktop.
Hsu's book on the building of Deep Blue is almost as partisan as Kasparov's comments.
Assuming this is the book you mean, I'd have to disagree. I read this over the holidays, and thought Hsu went out of his way to attempt to be impartial.
He obviously had a vested interest (as do you), but I didn't feel his book was in any way partisan - he wanted to win, but he was perfectly capable of dealing with the inevitable losses. As he's one of the participants, you have to take the comments about Kasparov's behaviour with a pinch of salt: but that's a very minor part of the book, and perfectly understandable given that it was an "I said/they said" situation.
It's a great book for finding out just how cobbled-together some of the early chess playing machines were - and that the kinds of problems they ran into along the way were incredibly mundane (fabrication problems, hardware failures, networks going down, last minute "this can't possibly hurt" changes to the code, etc). Although the book is pitched as being the story behind Deep Blue, a large chunk of it relates to the machines leading up to that point and the process by which Deep Blue came about (rather than that particular machine).
OS X's first API was cocoa from nextstep. To me, this makes cocoa the naitive API for the OS.
By that reasoning Mach is the only really "native" API in the system, since it was there first. Cocoa is only as "native" as any of the other frameworks in the system, not more so (it's not even particularly low-level - it's just an application framework).
But carbon is legacy and was added to the yellow box spec as a technology to bridge legacy classic code.
Heh, not quite - Carbon was added as a direct response to the flop that was Rhapsody (i.e., when the only migration path for every Mac developer bar the handful from Next was a complete rewrite). BTW, the "yellow box spec" referred specifically to what became Cocoa - Carbon was a parallel project to this, and was never part of the same spec.
Carbon isn't a "bridge" in any meaningful sense of the word, it's one of the standard system APIs. If it was for legacy code, why is so much new development (Carbon Events, HIViews, ATSUI, etc) taking place in that framework?
IE is still dog slow... it has taken a performance hit from being ported to OS X. Chimera, built from the ground up for OS X (and Im sure it contains carbon code too) is the better performer.
IE's poor performance has nothing whatsoever to do with it being written to the Carbon API - some of the slowest apps on the system are written to Cocoa (e.g., iCal), and some of the fastest are written to Carbon (e.g., games: everyone but Omnigroup uses Carbon). The point is that what makes an app slow has nothing to do with it using Cocoa or Carbon. These are just APIs to get events from the system and to display a UI - which in itself isn't really a performance bottleneck.
The whole "Cocoa is more native than Carbon" myth is exactly that, a myth. It was started by ex-Next executives as a way of disparaging the previous Mac OS APIs, and has unfortunately taken root amongst people who really should know better.
It seems that German Chancellor Gerhard Schroeder has succeeded in obtaining a injuction from a Hamburg court that forbids a UK newspaper from pubilshing details about an alleged extramarital affair.
Although note that the intent of this wasn't to quash publication in the UK - the injunction covers the international edition of the paper, which is normally published across Europe (including Germany).
That, and reminding German papers that Germany privacy laws are substantially stronger than UK privacy laws (Germany has a "right to privacy", the UK doesn't), is probably his point - not to attempt to extend jurisdiction over a UK entity.
It would be impossible to measure - even if you performed the "same" trial twice, with different sets of jurors, who's to say that a differing conclusion wouldn't have ben reached anyway.
Having said that, a large part of the legal tradition in countries outside the US is concerned with keeping this as bias-free "as possible" (the hope being that attempting to be bias free, even if it's unattainable, is better practice than not).
If you watch US pre-trial coverage compared to, say, European/Asian coverage of the same event, this is very pronounced (e.g., the recent sniper attacks). The media in the US are free to speculate on motive, opportunity, and even the actual guilt or innocence of the accused - this kind of reporting does not really take place outside the US.
This is often defended within the US as being the rights of a "free press", however most countries equate freedom with responsibility - the US press unfortunately has plenty of one, but very little of the other. I'm not assigning a value to this, just pointing out that culturally, most other societies require freedom of expression to be balanced by the rights of the accused (who have not been convicted, and are as "guilty" in the eyes of the law as the journalists covering their story - i.e., not at all until convicted).
You can not be serious - Tom Clancy is straight-to-Airport junk. There's just no comparison between him and someone like Ian (M) Banks or Jeff Noon: books should be to make you think, not to help you buff up on pointless military jargon.
Slashdot Mirror
but when almost everyone uses it to mean what the original poster did, then "begging the question" has taken a new meaning
Except that we're thankfully not at that stage yet - this usage is common amongst North Americans (as are errors such as using "loose" when they mean "lose"), but is not widespread elsewhere.
Afteward if they play it well, they will 'own' the linux game market
100% of a very small number is still a very small number.
What was it Kevin Mitnick said about social engineering?
I don't like butterscotch, but I do like vanilla. You don't see friggin holy wars over pudding, though, do you?
Hmm, no, I don't remember him saying that.
They employ top-notch journalists, and Markoff
Bahahahahaha... Markoff is well known in Apple circles for panning Apple in his newspaper columns as being doomed a couple of years ago while simultaneously hawking his book on how Apple was, guess what, doomed.
This included such episodes as predicting Apple was about to be bought by Sun, Apple was going to move to x86, Apple was going to adopt Windows NT, Apple was going to sell off QuickTime, etc, etc. Oh, and a particularly peculiar episode where he started stalking Gil Amelio (then Apple CEO) and turning up unannounced at his house late at night.
He's always been completely clueless about anything vaguely Apple related, so why should I trust a word he says about any other subject? He's a cheap hack - I wouldn't trust him further than I could throw him.
The problem is not with software intended to run on a mac. the problem is with software intended to run on a linux machine. hence these are not "bugs" from the linux perspective.
"Linux" has nothing to do with it - if it supports Mac OS X as a target then it's a *nix program, and not something specific to Linux. Heck, if it wanted to run under the excuse for a POSIX subsystem on NT it would also fail since NTFS uses the same model as HFS+ (case-insensitive and case-preserving).
I think this problem could be handled best if either apple abandoned canse insentivity everywhere except possibly at the finder level.
Never going to happen - Apple chose the current behaviour for a reason, not on a whim.
Twirlip, how do we deal with the case insensitivity in UFS. it occasionally happens that a linux package will contain a directory with two files like "HEAD" and head or ReadME and readMe of "configure" and CONFIGURE.
Report this as a bug to the maintainer of the package - if they're at all interested in supporting Mac OS X as a Unix platform, they will have to remove the dependency on a case-sensitive volume format (aside from some ex-NeXT users, and fanboys who don't know any better, the Mac volume format is HFS+).
If you have to use some software which requires UFS, the best workaround is to create a large enough UFS disk image and install onto that - saves having to dedicate a whole partition to UFS, and handy for dumping onto DVD if you want to move the "UFS world" to another machine.
This is directly due to IBM and Intel "opening" their design specs.
That would be "opening" in the sense of "fighting it tooth and nail" then?
The QuickTime file format has always been documented - there have been QuickTime content generating apps available on multiple platforms forever (in a past life I wrote some code to emit QuickTime VR movies for a 3D toolkit on Irix).
The problem is always the codec used to encode the data - but if you've come up with a codec that doesn't infringe anyone's patents, why/how should they care? The problem is that to date, nobody in the OSS world has done so.
That was Macworld 1998. He (Schiller) didn't actually throw it onto the floor, he jumped off a scaffold onto a bean bag while holding the iBook.
The demo was more about showing how AirPort kept working even if you shoogled it around, not really about bounce-testing an iBook^Wexecutive.
Um, no - Thomson stopped manufacturing PAL boxes last year, and Tivo UK are still looking for a new supplier. Or do you have a more recent source?
That doesn't explain a bad opening weekend.
Sure it does - it stunk so badly, people on the east coast were diving out of theatres and calling ahead to pre-warn people in line out west. Not to mention Sat/Sun (assuming "weekend" includes Friday night) being down due to people reading reactions online from the previous night's viewings.
The truth of the matter is that it didn't have a lot of people rushing to theaters to go see it. It kind of fell off the radar with all the other movies out.
Nice theory, but then you'd expect it to pick up over time as people get round to viewing it. Which they patently haven't done.
It failed because it sucked - plain and simple. It felt like an extended episode rather than a "film" (e.g., compare it with something like LoTR).
As you hover the mouse across it, the shape of the bar distorts and icons scale up, sometime to take up a significant fraction of the entire display. The icons always look beautiful.
Yes, and it's all done with pixmaps - the largest style of icon applications can currently provide on Mac OS X is 128x128x32.
Larger icons may be more necessary over time (although display resolutions aren't increasing dramatically - it'll be a while before you get 5000x5000 on a consumer CRT/LCD), however Mac OS X manages quite well with 128x128. They undoubtably looked at using PDF for icons within Mac OS X as well, however the benefits are pretty marginal today.
So is the scaling algorithm more or less expensive than the SVG renderer?
On a desktop CPU, scaling a bitmap will probably be cheaper - either by using a vector unit like AltiVec, or by clever use of a GPU (like Mac OS X's Quartz Extreme - although that's really used for compositing rather than transformation at the moment).
What about CPUs with no hardware floating point (goes for both SVG and bitmap)?
I suspect bitmaps would be faster - scaling can be done with two lookup tables (one for each dimension), which are either pre-calculated with a real FPU or set up at run-time with fixed point.
What about scaling to print?
Yes, a vector image is more suitable for this case. But icons just aren't printed all that often - certainly not nearly so often as "pictures".
There's no hard and fast line between an icon and a picture, but icons have a fairly well defined role in current user interfaces: they're small pictograms displayed on screen (and even assuming monitor resolutions keep increasing, 128x128 or even 256x256 is going to be big enough for a while).
Of course, since SVG can contain both vector and pixmap data you could use it as a container for either form - depending on what you need it for. I suspect pixmaps would be more common however: the way most people generate icons on Mac OS X is to start with a photo or a screenshot, rather than working in Illustrator and rasterizing at the end (although, true, some people do that as well - their icons tend to look a bit over-Aquified though).
It uses scalable bitmaps, which is nice, but they can't go any bigger than 256x256
They're 128x128 actually.
Same idea in Mac OS X - which calls them "badges". The API lets you composite one icon reference on top of another and draw it as a single entity (or to find out if an icon reference is actually a composite).
Personally I suspect there's not a great deal of point in making icons vector: 128x128x32 with a decent scaling algorithm (and an optional set of pre-scaled images at smaller sizes) seems to cover pretty much everything. At least for the tasks icons are typically used for. Anything larger than 128x128 is turning into a picture rather than an icon (yeah, you could use the same format for both, but why bother - 99% of the time an icon is just blitted to the screen or used for hit testing, both of which an 32-bit pixmap is ideal for).
Another excellent book along these lines is Gene Kranz's Failure Is Not An Option (Kranz was the flight director for Apollo 13, amongst others).
It really brings home just how complex these enterprises are - this really is the cutting edge of what we as a species can currently accomplish.
OS X is no more Unix than Linux is
:-)
Of course. But if you want to be picky, you'll note that I said "Unix", not "UNIX".
1. Harrassing Aqua-ish theme makers. As Apple should know, you can't patent "look and feel" -- as their failed case against MS demonstrated.
The "harassment" was due to people copying and pasting widgets directly out of Mac OS X and passing them off as their own. And no, that's not what the failed "look and feel" case demonstrates - that case was lost due to the slack language Apple used in the contract they signed with MS. They gave MS more rights than they thought they had, and when they went to court this came out - hence they lost.
You most certainly can sue over "look and feel", due to a concept known as "trade dress". If I set up a MacDonalds fast food chain with a couple of golden-Ms, you can be I'd have a suit slapped on me within minutes.
Refusing to release a Sorenson codec enabled player or library for Linux, effectively locking Linux users out of an increasing majority of all Internet video content and thus making Linux unviable to end users
Mod -1, Boo Fucking Hoo. Apple signed a contract with Sorenson. Sorenson signed a contract with Apple. Those two companies entered into a deal whereby you're not going to get Sorenson's code for free on your platform. Get over it.
Instead of whining about it, why don't you get off your ass and write a better codec? What's that, it's hard? Well that's why people can and do build businesses around it...
3. Undercutting development of established Open Source projects, like Mozilla and XFree86, by pushing less open alternatives and thus both cutting their mindshare and draining developer talent.
Apple doesn't owe Mozilla anything - you've as much right to demand they use Mozilla as I've got to demand the Mozilla developers come over and paint my house. If an Open Source project can't stand on its own merits, why should it succeed?
And before someone replies 'but now it supports X11', the point is that they aren't the 'default' systems under MacOS -- which means "native" GUI MacOS X applications are useless to Linux
Yeah, and your average Gnome/KDE app won't run out of the box on a Mac either - your point is what? What Apple choses to make their default is their business - face it, X11 caters for a minority, and it's just not that useful to Apple's target market.
It's definitely a prudent move for Apple to ensure it runs reasonably well, since they want to see if they can expand their target market into the Unix workstation market (or what's left of it), but it's by no means their main focus.
In short: Apple is not Linux's friend, and these articles that claim otherwise are stupid and tiresome.
Apple is absolutely Linux's "friend" (in so far as a large company can be friends with a bunch of source files). For god's sake, it's Unix. On The Desktop.
But I don't think that this part you included was in the original article...
You heard that whoosing sound? That was the sound of a joke. Passing over your head.
Hsu's book on the building of Deep Blue is almost as partisan as Kasparov's comments.
Assuming this is the book you mean, I'd have to disagree. I read this over the holidays, and thought Hsu went out of his way to attempt to be impartial.
He obviously had a vested interest (as do you), but I didn't feel his book was in any way partisan - he wanted to win, but he was perfectly capable of dealing with the inevitable losses. As he's one of the participants, you have to take the comments about Kasparov's behaviour with a pinch of salt: but that's a very minor part of the book, and perfectly understandable given that it was an "I said/they said" situation.
It's a great book for finding out just how cobbled-together some of the early chess playing machines were - and that the kinds of problems they ran into along the way were incredibly mundane (fabrication problems, hardware failures, networks going down, last minute "this can't possibly hurt" changes to the code, etc). Although the book is pitched as being the story behind Deep Blue, a large chunk of it relates to the machines leading up to that point and the process by which Deep Blue came about (rather than that particular machine).
OS X's first API was cocoa from nextstep. To me, this makes cocoa the naitive API for the OS.
By that reasoning Mach is the only really "native" API in the system, since it was there first. Cocoa is only as "native" as any of the other frameworks in the system, not more so (it's not even particularly low-level - it's just an application framework).
But carbon is legacy and was added to the yellow box spec as a technology to bridge legacy classic code.
Heh, not quite - Carbon was added as a direct response to the flop that was Rhapsody (i.e., when the only migration path for every Mac developer bar the handful from Next was a complete rewrite). BTW, the "yellow box spec" referred specifically to what became Cocoa - Carbon was a parallel project to this, and was never part of the same spec.
Carbon isn't a "bridge" in any meaningful sense of the word, it's one of the standard system APIs. If it was for legacy code, why is so much new development (Carbon Events, HIViews, ATSUI, etc) taking place in that framework?
IE is still dog slow... it has taken a performance hit from being ported to OS X. Chimera, built from the ground up for OS X (and Im sure it contains carbon code too) is the better performer.
IE's poor performance has nothing whatsoever to do with it being written to the Carbon API - some of the slowest apps on the system are written to Cocoa (e.g., iCal), and some of the fastest are written to Carbon (e.g., games: everyone but Omnigroup uses Carbon). The point is that what makes an app slow has nothing to do with it using Cocoa or Carbon. These are just APIs to get events from the system and to display a UI - which in itself isn't really a performance bottleneck.
The whole "Cocoa is more native than Carbon" myth is exactly that, a myth. It was started by ex-Next executives as a way of disparaging the previous Mac OS APIs, and has unfortunately taken root amongst people who really should know better.
It seems that German Chancellor Gerhard Schroeder has succeeded in obtaining a injuction from a Hamburg court that forbids a UK newspaper from pubilshing details about an alleged extramarital affair.
Although note that the intent of this wasn't to quash publication in the UK - the injunction covers the international edition of the paper, which is normally published across Europe (including Germany).
That, and reminding German papers that Germany privacy laws are substantially stronger than UK privacy laws (Germany has a "right to privacy", the UK doesn't), is probably his point - not to attempt to extend jurisdiction over a UK entity.
It would be impossible to measure - even if you performed the "same" trial twice, with different sets of jurors, who's to say that a differing conclusion wouldn't have ben reached anyway.
Having said that, a large part of the legal tradition in countries outside the US is concerned with keeping this as bias-free "as possible" (the hope being that attempting to be bias free, even if it's unattainable, is better practice than not).
If you watch US pre-trial coverage compared to, say, European/Asian coverage of the same event, this is very pronounced (e.g., the recent sniper attacks). The media in the US are free to speculate on motive, opportunity, and even the actual guilt or innocence of the accused - this kind of reporting does not really take place outside the US.
This is often defended within the US as being the rights of a "free press", however most countries equate freedom with responsibility - the US press unfortunately has plenty of one, but very little of the other. I'm not assigning a value to this, just pointing out that culturally, most other societies require freedom of expression to be balanced by the rights of the accused (who have not been convicted, and are as "guilty" in the eyes of the law as the journalists covering their story - i.e., not at all until convicted).
You can not be serious - Tom Clancy is straight-to-Airport junk. There's just no comparison between him and someone like Ian (M) Banks or Jeff Noon: books should be to make you think, not to help you buff up on pointless military jargon.