The level of indentation is plainly visible, but it looks the same (unless you're using an editor that specially marks tabs somehow) whether you're using spaces or tabs. Therefore, the tab characters are effectively invisible.
As for your comment about "wrestling with levels of brackets", what? Do you use Notepad to write code? As someone who likes Python a lot, but is also familiar and comfortable with several other languages, that is utter nonsense. Indenting is fairly straightforward in Python, but outdenting is insane! Let's see, I've got the try block and the for block and the if and the if, and now I need to outdent to match up with...one of those. Which is positioned...somewhere. With braces, it's easy to count the braces, or (in most editors), simply put your cursor on the brace and have the editor automatically show you where the block starts. Furthermore, re-indenting with braces is easy, because the editor has braces to guide it. (Unless, again, you're using notepad or something else unsuitable for the task of programming.) With Python, you have to manually inspect the locations of the previous blocks, and god help you if you outdent improperly, because nothing will offer you any hint that you've done so, except the misbehavior of your code at run-time.
(Let's not even get into what happens in Python if you indent by four, and then by three, and then outdent by eight, or some other doesn't-quite-add-up combination. Python is a great language, but its indentation stuff is its biggest flaw, by far.)
p.s. I realize I've violated the unwritten rules of slashdot by actually reading the article and commenting on what it says, instead of leaping to snap judgment based on the headline alone. In my defense, I actually read the article yesterday, before it was posted to slashdot.:)
I like the "to announce" part. Like, if they haven't announced it, why are you reporting on it? Maybe there's a reason they haven't actually announced it yet! Perhaps the data is tentative and admits of another explanation, which, on further review, will prove to be true. Perhaps it's simply one guy's wild-ass guess based on incomplete data.
Contacted by AFP, ESO spokesman Richard Hook said he is aware of the report, but refused to confirm or deny it. "We are not making any comment," he said.
Maybe, just maybe, there's a reason he's not making any comment? Like, they want to avoid making false statements in public and embarrassing themselves? Quite unlike certain (most?) Internet "news" sites which are perfectly happy both to make false statements and to embarrass themselves? "Who cares? Just give us those clicks!"
Anyway, this is pretty cool if confirmed, but at this point, I'm treating it with all the seriousness it deserves, which is approximately zero.
I still have one gopher site bookmarked, although it's been dead for a while (and modern browsers no longer recognize "gopher://" as a valid URI prefix). I simply haven't got the heart to delete it. Of course, even at the time I added it, gopher was nearly dead as a protocol in general. I mostly only added it because I was astounded that I'd stumbled across a still-running site, and that my browser, at the time, could still talk to it.
This story was simply posted to gather evidence confirming the fact that slashdot is full of old pharts, yes?:)
What are you on about? Two months? Closer to two years! LO started in 2010. OpenOffice was, as far as anyone could tell, a dead project at that time. The LO folks spent a full year cleaning up the code before making their initial release in early 2011. It was half a year later that Oracle finally (after a year and a half!) announced they'd be relicensing the old OOo code and donating to Apache. What was LO supposed to do? Stop everything and wait to see if this promised code drop (of code they'd already spent a year cleaning up, and another six months improving and adding features to) actually happened, and start over from scratch? That would be dumb!
Now, for a while there, things might have gone in all sorts of different ways. I installed both, and was happy to go with whichever one turned out the best. But AOO completely failed to attract developers. They had some strong support from IBM for a while, but IBM seems to have abandoned them at this point. They're down to a tiny handful of developers, and they currently have a major security bug (CVE 2016-1513), and they can't even figure out how to get updates to their users, even though they have a patch!
I've got no skin in the game. I like Apache too. Have several friends who are members of the Foundation. But it's clear to me at this point that LO has won, and AOO is a dead project walking. AOO has about a dozen people who have contributed in the last year. LO has hundreds. LO has more changesets accepted per day than AOO has in months! LO has backing from several major companies, most notably RedHat and Collabora. AOO lost their only corporate sponsor, IBM, over a year ago.
You use what you want to. AOO is gone from my system, and I don't miss it at all. Being supported by Apache doesn't mean much if you haven't got any developers, and can't even figure out how to get a security fix out to your users!
Well in the stable 2.8.x series you only have 8 bit support, not 16/32 bit as far as I know.
The 2.6 series had 8 bits per channel (32 bits per pixel with the standard four-channel RGBA). The 2.8 series added 16 bits per channel internally by switching to GEGL, but didn't modify the UI to take full advantage. The 2.10 series (of which 2.9.4 is the latest dev pre-release) fixes that.
Nobody uses 32 bits per channel. Standard computer hardware only supports 8 bits per channel. The only reasons to even include 16 bits per channel are: it is provided by some cameras, and you don't want to lose precision, and it makes some transformations less lossy.
In essence, what he's saying is: "We don't want a back door. We just want a back door!" Weakened encryption *is* a back door! And more than even the usual back door, it's a back door available to everyone! (Although that's true to some extent of every back door.)
Why would anyone expect a CEO—even of a tech company—to have any idea about computer security? That's like expecting a POTUS to have a deep knowledge of battlefield strategy, simply because they're Commander-in-Chief of the US Armed Forces.
Yeah? And imagine what it would be like if the crossing were run by a private company with financial incentive to discover contraband. We'd have 100% "bend and spread 'em!" I'll take good old-fashioned government incompetence over corporate goons with a financial interest in fingering my bunghole any day!
Yeah, C++11 was a major improvement; much of the extra "complexity" actually ended up making a lot of things much simpler. The new "auto", the new lambdas, and the new "smart" for loops, between them, allow writing simple, straightforward code to do things which would have required a tangled, opaque, and fragile mess of barely-readable code in older versions of C++.
Rvalue-references and std::move are a little trickier to understand, but fortunately, they can provide benefits even if you don't use them directly, since they greatly improve the performance of the standard library container classes and such. Even if you don't change your code!
The Three Laws only apply to fictional robots. Because they're fictional! (The "laws", that is.) Expecting them to apply to actual robots is simply silly (to use a more polite term than it probably deserves).
Even if we had actual AI in the sense it's usually used in science fiction, that wouldn't make the Three Laws magically pop into existence. They'd need to be programmed, and to the best of my knowledge, nobody has written that code yet.
Good API design is hard work, requires expertise to do it, is not trivial and does guide implementation.
None of which is a reason for something to be copyrightable! If hard work alone were copyrightable, every ditch digger in the world would be owed royalties from every ditch they've dug. If requires-expertise made something copyrightable, then I should be able to claim copyright on Poe's "The Raven" because I can recite it from memory. If guides-implementation made something copyrightable, then again, those ditch diggers should get royalties from the plumbers who laid pipe in those ditches.
In the case of designing a good API, most of the hard work comes from figuring out what people are likely to expect, and matching that as closely as possible. That's pretty much the opposite of "creativity", which is what gives something copyrightability. Figuring out what people are likely to expect and matching that as closely as possible falls under the category of "scenes a faire", which is explicitly excluded from copyrightability.
A sufficiently creative API might be copyrightable, but it would also almost certainly be a horrible API, not a good one, since by definition it wouldn't be using the obvious, expected choices.
I think "they redeemed themselves" is a bit strong, but I do agree that this sounds like something that should be counted on the positive side of the ledger.
Yahoo may be the first since "the reforms of the USA Freedom Act", but the Internet Archive fought and won back in '08. I'm pretty sure Slashdot covered it when it happened, but I'm too lazy to hunt down the link.
It's not clear to me if the USA Freedom Act made this harder (in which case, why are we calling them "reforms"?) or easier. That would make this story a lot more interesting.
(The EFF has the Archive's slightly-redacted NSL on file, for anyone who's interested in comparisons.)
That's not the interface. That's linking with the actual code. Which can be (and is) copyright.
The reason using readline but not including the readline code is still a copyvio is that the only possible use for such code is to create a program linked with the (actually copyrighted) readline library. And the law takes intent into account. If you intend to give people a copyright-violating program, trickery of making them get the copyright-violating part on their own are considered just that: tricks. That's why NeXT gave up and released the code to their Objective-C back end after the FSF objected to their use of GCC. And that was a standalone binary!
Now, in the case of readline, you could get around the problem (and someone did, in a similar case involving a different library) by creating your own stub library which used the same (not-copyrighted) API. Then (and only then), the use of the API would no longer signal your clear intent to distribute a copyright-violating program.
That actually does work. There was even a real-world example: someone created a plugin for some GPL'd app that used the (proprietary at the time) RSA libraries. FSF claimed the code couldn't be distributed, because the intent was clearly to link GPL'd and non-GPL'd code into a single app. So the guy made a stub library with the same interface as the RSA library, and the FSF dropped their objections. Even though the stub library did nothing.
Of course, in such a case, you couldn't distribute the complete system, because that would clearly still be mixing the GPL and non-GPL code--you would no longer be able to call it "mere aggregation"--but he was able to distribute the plugin by itself.
As anonymous coward said, the GPL is not an EULA, it's a distribution license. It's also completely optional. Unless you want to redistribute the code, you can completely ignore the GPL and simply use the copy under normal copyright terms. Therefore, until I actually distribute some of this software myself, there is no license!
Likewise, the BSD and MIT license, which simply say "you can copy/modify this as long as you preserve attributions" and not much else. That's not a user license; that's a distribution license.
Bottom line: copyright is supposed to protect creative and original works. You cannot copyright a simple list of facts, no matter how much research it took. Languages (computer or ConLan) are generally considered tools for expression; something written in Klingon can be copyrighted, but the Klingon language itself cannot be. A dictionary defining the meanings of Klingon words can be copyrighted, but not the language itself.
Note that no computer language ever has been copyrighted. Implementations can be copyrighted, of course, but the languages themselves are not.
APIs are simply the language you use to access the functionality of a library. The library may be copyrighted, like the dictionary of Klingon, but the interface is simply the words of the language of the library, used for creative expression by the application programmer. This is more-or-less the heart of the matter.
Beyond that, purely functional language (not a functional language, but language which is required for functionality) cannot be copyrighted. If there's only one way to describe something, you can't copyright that, because it's defined by the problem-space, so no creativity is required. In most languages, a simple swap function would probably not be copyrightable, because there's really only one, or maybe two, sane ways to implement that. Writing a word processor, on the other hand, allows all sorts of opportunities for creativity.
(The irony of this last point is that a really badly designed API would be more likely to be copyrightable than a sensible, straightforward one, since the sensible, straightforward one is constrained by the problem-space.)
In the case of macros, the names and arguments of the macros would not* be copyrightable, but the bodies would be (assuming they weren't trivial, like swap).
Anyway, I'm really not the best one to explain all this. If you want a really good explanation, I recommend reading the transcripts of the final judgment in the original suit. Its conclusion may have been overturned by the appeals court, but it clearly lays out the reasons why APIs until then had not been considered copyrightable. It also lists a number of applicable precedents, which are still quite relevant.
* At least, till Oracle v. Google, they would not have been. Now they're merely probably not copyrightable.
I'll be glad to if you can tell me where it is. The only thing on my system that has an EULA is a game I bought about 15 years ago. (Oh, and flash, but I've currently go that disabled.)
Before Oracle v. Google, everyone assumed (based on extensive legal precedent) that APIs were not subject to copyright at all. Yet the GPL was just fine. Why would the GPL be threatened all of a sudden just because one more API turned out to be copyable?
The only tangible result of this case has been a very slight strengthening of copyrights, since the appeals court rules that APIs might be copyrightable under certain circumstances. How does strengthening copyright weaken a license that relies on copyright?
This is either monumental stupidity, or outright shilling. Hanlon's razor suggests I ought to go with the former, but I'm going to wait and see.
Hard to say, since it depends entirely on what sort of thing you like!
If you want technical stuff that isn't gory details, something like Fred Brooks' The Mythical Man-Month is probably worth a shot. A lot of stuff from this book has passed into common wisdom, but actually reading the first-hand accounts makes it far more real!
If you want lighter entertainment reading that's vaguely computer related, I can strongly recommend Charles Stross's "The Laundry Files" books. These are a mash-up of spy thriller and Lovecraftian horror with a hacker protagonist, in a world where computers are the ultimate key to summoning up tentacled creatures from beyond.
But if your favorite author is Dostoevsky, then this may not be to your tastes. As I say, it depends entirely on what sort of thing you like.
So applying force is the key? If I hurl a rock with a gigantic catapult, and it goes hundreds of miles, it's not traveling, because no force is being applied after it leaves the catapult? Or does only half the distance it moves count as travel, because the second half is simply falling?
If I ride my bicycle over a mountain, does only half of the journey count as travel, because I coasted the second half of the trip? If I rode my bike from Denver to LA, would I have traveled a shorter distance than if I'd gone the other way, because so much more of it was downhill?
The ISS happens to be traveling in a path that, aside from the initial launch, is pretty much all downhill, but claiming that it's not actually traveling because of that makes about as much sense as the claim about Denver->LA.
Slashdot Mirror
The level of indentation is plainly visible, but it looks the same (unless you're using an editor that specially marks tabs somehow) whether you're using spaces or tabs. Therefore, the tab characters are effectively invisible.
As for your comment about "wrestling with levels of brackets", what? Do you use Notepad to write code? As someone who likes Python a lot, but is also familiar and comfortable with several other languages, that is utter nonsense. Indenting is fairly straightforward in Python, but outdenting is insane! Let's see, I've got the try block and the for block and the if and the if, and now I need to outdent to match up with...one of those. Which is positioned...somewhere. With braces, it's easy to count the braces, or (in most editors), simply put your cursor on the brace and have the editor automatically show you where the block starts. Furthermore, re-indenting with braces is easy, because the editor has braces to guide it. (Unless, again, you're using notepad or something else unsuitable for the task of programming.) With Python, you have to manually inspect the locations of the previous blocks, and god help you if you outdent improperly, because nothing will offer you any hint that you've done so, except the misbehavior of your code at run-time.
(Let's not even get into what happens in Python if you indent by four, and then by three, and then outdent by eight, or some other doesn't-quite-add-up combination. Python is a great language, but its indentation stuff is its biggest flaw, by far.)
I'd mod you up if I hadn't already posted. :)
Once again, I think we can turn to Betteridge's law of headlines: "Any headline that ends in a question mark can be answered by the word no." :)
Haven't used KDE since the V4 release myself, but I still tend to suspect that Betteridge probably applies here.
p.s. I realize I've violated the unwritten rules of slashdot by actually reading the article and commenting on what it says, instead of leaping to snap judgment based on the headline alone. In my defense, I actually read the article yesterday, before it was posted to slashdot. :)
I like the "to announce" part. Like, if they haven't announced it, why are you reporting on it? Maybe there's a reason they haven't actually announced it yet! Perhaps the data is tentative and admits of another explanation, which, on further review, will prove to be true. Perhaps it's simply one guy's wild-ass guess based on incomplete data.
Maybe, just maybe, there's a reason he's not making any comment? Like, they want to avoid making false statements in public and embarrassing themselves? Quite unlike certain (most?) Internet "news" sites which are perfectly happy both to make false statements and to embarrass themselves? "Who cares? Just give us those clicks!"
Anyway, this is pretty cool if confirmed, but at this point, I'm treating it with all the seriousness it deserves, which is approximately zero.
I still have one gopher site bookmarked, although it's been dead for a while (and modern browsers no longer recognize "gopher://" as a valid URI prefix). I simply haven't got the heart to delete it. Of course, even at the time I added it, gopher was nearly dead as a protocol in general. I mostly only added it because I was astounded that I'd stumbled across a still-running site, and that my browser, at the time, could still talk to it.
This story was simply posted to gather evidence confirming the fact that slashdot is full of old pharts, yes? :)
What are you on about? Two months? Closer to two years! LO started in 2010. OpenOffice was, as far as anyone could tell, a dead project at that time. The LO folks spent a full year cleaning up the code before making their initial release in early 2011. It was half a year later that Oracle finally (after a year and a half!) announced they'd be relicensing the old OOo code and donating to Apache. What was LO supposed to do? Stop everything and wait to see if this promised code drop (of code they'd already spent a year cleaning up, and another six months improving and adding features to) actually happened, and start over from scratch? That would be dumb!
Now, for a while there, things might have gone in all sorts of different ways. I installed both, and was happy to go with whichever one turned out the best. But AOO completely failed to attract developers. They had some strong support from IBM for a while, but IBM seems to have abandoned them at this point. They're down to a tiny handful of developers, and they currently have a major security bug (CVE 2016-1513), and they can't even figure out how to get updates to their users, even though they have a patch!
I've got no skin in the game. I like Apache too. Have several friends who are members of the Foundation. But it's clear to me at this point that LO has won, and AOO is a dead project walking. AOO has about a dozen people who have contributed in the last year. LO has hundreds. LO has more changesets accepted per day than AOO has in months! LO has backing from several major companies, most notably RedHat and Collabora. AOO lost their only corporate sponsor, IBM, over a year ago.
You use what you want to. AOO is gone from my system, and I don't miss it at all. Being supported by Apache doesn't mean much if you haven't got any developers, and can't even figure out how to get a security fix out to your users!
The 2.6 series had 8 bits per channel (32 bits per pixel with the standard four-channel RGBA). The 2.8 series added 16 bits per channel internally by switching to GEGL, but didn't modify the UI to take full advantage. The 2.10 series (of which 2.9.4 is the latest dev pre-release) fixes that.
Nobody uses 32 bits per channel. Standard computer hardware only supports 8 bits per channel. The only reasons to even include 16 bits per channel are: it is provided by some cameras, and you don't want to lose precision, and it makes some transformations less lossy.
In essence, what he's saying is: "We don't want a back door. We just want a back door!" Weakened encryption *is* a back door! And more than even the usual back door, it's a back door available to everyone! (Although that's true to some extent of every back door.)
Why would anyone expect a CEO—even of a tech company—to have any idea about computer security? That's like expecting a POTUS to have a deep knowledge of battlefield strategy, simply because they're Commander-in-Chief of the US Armed Forces.
Yeah? And imagine what it would be like if the crossing were run by a private company with financial incentive to discover contraband. We'd have 100% "bend and spread 'em!" I'll take good old-fashioned government incompetence over corporate goons with a financial interest in fingering my bunghole any day!
Yeah, C++11 was a major improvement; much of the extra "complexity" actually ended up making a lot of things much simpler. The new "auto", the new lambdas, and the new "smart" for loops, between them, allow writing simple, straightforward code to do things which would have required a tangled, opaque, and fragile mess of barely-readable code in older versions of C++.
Rvalue-references and std::move are a little trickier to understand, but fortunately, they can provide benefits even if you don't use them directly, since they greatly improve the performance of the standard library container classes and such. Even if you don't change your code!
Sounds like dicta. Not as big a deal as it could be then, since dicta are not binding.
From the link I gave: "[dicta] therefore are individual views of the author of the opinion and not binding in subsequent cases as legal precedent."
The Three Laws only apply to fictional robots. Because they're fictional! (The "laws", that is.) Expecting them to apply to actual robots is simply silly (to use a more polite term than it probably deserves).
Even if we had actual AI in the sense it's usually used in science fiction, that wouldn't make the Three Laws magically pop into existence. They'd need to be programmed, and to the best of my knowledge, nobody has written that code yet.
Good API design is hard work, requires expertise to do it, is not trivial and does guide implementation.
None of which is a reason for something to be copyrightable! If hard work alone were copyrightable, every ditch digger in the world would be owed royalties from every ditch they've dug. If requires-expertise made something copyrightable, then I should be able to claim copyright on Poe's "The Raven" because I can recite it from memory. If guides-implementation made something copyrightable, then again, those ditch diggers should get royalties from the plumbers who laid pipe in those ditches.
In the case of designing a good API, most of the hard work comes from figuring out what people are likely to expect, and matching that as closely as possible. That's pretty much the opposite of "creativity", which is what gives something copyrightability. Figuring out what people are likely to expect and matching that as closely as possible falls under the category of "scenes a faire", which is explicitly excluded from copyrightability.
A sufficiently creative API might be copyrightable, but it would also almost certainly be a horrible API, not a good one, since by definition it wouldn't be using the obvious, expected choices.
I think "they redeemed themselves" is a bit strong, but I do agree that this sounds like something that should be counted on the positive side of the ledger.
Yahoo may be the first since "the reforms of the USA Freedom Act", but the Internet Archive fought and won back in '08. I'm pretty sure Slashdot covered it when it happened, but I'm too lazy to hunt down the link.
It's not clear to me if the USA Freedom Act made this harder (in which case, why are we calling them "reforms"?) or easier. That would make this story a lot more interesting.
(The EFF has the Archive's slightly-redacted NSL on file, for anyone who's interested in comparisons.)
That's not the interface. That's linking with the actual code. Which can be (and is) copyright.
The reason using readline but not including the readline code is still a copyvio is that the only possible use for such code is to create a program linked with the (actually copyrighted) readline library. And the law takes intent into account. If you intend to give people a copyright-violating program, trickery of making them get the copyright-violating part on their own are considered just that: tricks. That's why NeXT gave up and released the code to their Objective-C back end after the FSF objected to their use of GCC. And that was a standalone binary!
Now, in the case of readline, you could get around the problem (and someone did, in a similar case involving a different library) by creating your own stub library which used the same (not-copyrighted) API. Then (and only then), the use of the API would no longer signal your clear intent to distribute a copyright-violating program.
That actually does work. There was even a real-world example: someone created a plugin for some GPL'd app that used the (proprietary at the time) RSA libraries. FSF claimed the code couldn't be distributed, because the intent was clearly to link GPL'd and non-GPL'd code into a single app. So the guy made a stub library with the same interface as the RSA library, and the FSF dropped their objections. Even though the stub library did nothing.
Of course, in such a case, you couldn't distribute the complete system, because that would clearly still be mixing the GPL and non-GPL code--you would no longer be able to call it "mere aggregation"--but he was able to distribute the plugin by itself.
As anonymous coward said, the GPL is not an EULA, it's a distribution license. It's also completely optional. Unless you want to redistribute the code, you can completely ignore the GPL and simply use the copy under normal copyright terms. Therefore, until I actually distribute some of this software myself, there is no license!
Likewise, the BSD and MIT license, which simply say "you can copy/modify this as long as you preserve attributions" and not much else. That's not a user license; that's a distribution license.
You asked a mouthful there!
Bottom line: copyright is supposed to protect creative and original works. You cannot copyright a simple list of facts, no matter how much research it took. Languages (computer or ConLan) are generally considered tools for expression; something written in Klingon can be copyrighted, but the Klingon language itself cannot be. A dictionary defining the meanings of Klingon words can be copyrighted, but not the language itself.
Note that no computer language ever has been copyrighted. Implementations can be copyrighted, of course, but the languages themselves are not.
APIs are simply the language you use to access the functionality of a library. The library may be copyrighted, like the dictionary of Klingon, but the interface is simply the words of the language of the library, used for creative expression by the application programmer. This is more-or-less the heart of the matter.
Beyond that, purely functional language (not a functional language, but language which is required for functionality) cannot be copyrighted. If there's only one way to describe something, you can't copyright that, because it's defined by the problem-space, so no creativity is required. In most languages, a simple swap function would probably not be copyrightable, because there's really only one, or maybe two, sane ways to implement that. Writing a word processor, on the other hand, allows all sorts of opportunities for creativity.
(The irony of this last point is that a really badly designed API would be more likely to be copyrightable than a sensible, straightforward one, since the sensible, straightforward one is constrained by the problem-space.)
In the case of macros, the names and arguments of the macros would not* be copyrightable, but the bodies would be (assuming they weren't trivial, like swap).
Anyway, I'm really not the best one to explain all this. If you want a really good explanation, I recommend reading the transcripts of the final judgment in the original suit. Its conclusion may have been overturned by the appeals court, but it clearly lays out the reasons why APIs until then had not been considered copyrightable. It also lists a number of applicable precedents, which are still quite relevant.
* At least, till Oracle v. Google, they would not have been. Now they're merely probably not copyrightable.
Read the goddam EULA
I'll be glad to if you can tell me where it is. The only thing on my system that has an EULA is a game I bought about 15 years ago. (Oh, and flash, but I've currently go that disabled.)
Before Oracle v. Google, everyone assumed (based on extensive legal precedent) that APIs were not subject to copyright at all. Yet the GPL was just fine. Why would the GPL be threatened all of a sudden just because one more API turned out to be copyable?
The only tangible result of this case has been a very slight strengthening of copyrights, since the appeals court rules that APIs might be copyrightable under certain circumstances. How does strengthening copyright weaken a license that relies on copyright?
This is either monumental stupidity, or outright shilling. Hanlon's razor suggests I ought to go with the former, but I'm going to wait and see.
Hard to say, since it depends entirely on what sort of thing you like!
If you want technical stuff that isn't gory details, something like Fred Brooks' The Mythical Man-Month is probably worth a shot. A lot of stuff from this book has passed into common wisdom, but actually reading the first-hand accounts makes it far more real!
If you want lighter entertainment reading that's vaguely computer related, I can strongly recommend Charles Stross's "The Laundry Files" books. These are a mash-up of spy thriller and Lovecraftian horror with a hacker protagonist, in a world where computers are the ultimate key to summoning up tentacled creatures from beyond.
But if your favorite author is Dostoevsky, then this may not be to your tastes. As I say, it depends entirely on what sort of thing you like.
So applying force is the key? If I hurl a rock with a gigantic catapult, and it goes hundreds of miles, it's not traveling, because no force is being applied after it leaves the catapult? Or does only half the distance it moves count as travel, because the second half is simply falling?
If I ride my bicycle over a mountain, does only half of the journey count as travel, because I coasted the second half of the trip? If I rode my bike from Denver to LA, would I have traveled a shorter distance than if I'd gone the other way, because so much more of it was downhill?
The ISS happens to be traveling in a path that, aside from the initial launch, is pretty much all downhill, but claiming that it's not actually traveling because of that makes about as much sense as the claim about Denver->LA.