I think they're both quite likely, and having one pseudo-unavailable due to the other is not good. Further, "where to buy" is a questions trivially solvable via many means including 411, the phone book, asking a friend, etc. The "detailed information on adjustment" is information that you may not e able to acquire anywhere else.
In some environments two weeks may be a long time, but the last time I had to use 2k professionally, I lost around 100 dollars in revenue for the time a reboot took. I put off rebooting for the longest possible time while there for this reason, which generally was only about two weeks before swapping became unworkable.
I guess the right solution would have been to reboot the box on saturday or so when no one was there, but I'm not sure that I had the rights to do such a thing.
I wasn't criticizing the specific, but the general. It happens a lot and mailing lists are focused, but externally read. Making things clear as to WHY they don't work and WHY you shouldn't do them is more effective than simply spouting that it is so.
Basically, lack of clarity reaps more trouble later.
Ideally/dev/random is fed by a good source of raw stochastic randomness along with other nondeterministic system events into a pool of entropy which is stirred etc. etc.
If you don't have a good source of raw stochastic randomness (like thermal noise in the intel 8xx chipset or freewheeling oscillators in the new via CPU), then/dev/random BLOCKS until it can generate enough entropy to be above an acceptable threshhold. Practically speaking, the user can bang away on the (local) keyboard if necessary to generate such randomness.
This is, of course, the whole POINT of/dev/random. You don't create a whole device to just recreate rand().
------
But yes, good crypto is HARD to write and HARD to identify flaws in. This obvious fact seems to sometimes escape cryptographers when they review inexpertly created crypto software, who lament endlessly that people get it wrong, and sometimes get sufficiently exasperated to even identify the flaws in comprehensible terms. "This code listing should be self explanatory" being a key sin here.
It's good that someone keeps after 'hobbyist crypto' authors to point out that their stuff is dangerous though. Is there a good communications outreach channel from the crypto community to the general programming community about the dangers of inexpert practice? I'd imagine a website dissecting a few projects in detail could drive home the message: If you don't really know, you're going to do it wrong.
Computer Industry legend says that the IBM PC design team wanted to use the 68000 but that there was a pre-existing industry deal struck with Intel that allowed them to use the 8080 for super-cheap.
It costs in equipment, it costs in time, it costs in verifying the reliability of all the parts, and it costs in verifying the reliability of the switchover-on-fail procedure.
Unless you have the organization to keep up all the necessary maintenance on a redundant system, it can become _less_ reliable than a non-redunant one.
Thus, you should not deploy it in all situations. Depending upon the level of investment in the service, a single server can be the more reliable, as well as cheaper, solution.
Right, because of all the embedded development sales opportunities that were going towards BSDI??
Let's review. Was BSDI a highly successful embedded operating system? Was BSDI known for being used in realtime and/or small-scaled operating environments across tens of architectures?
Answers: No, no, and no.
Aside: pSOS was bought for tools and customer acquisition. It was a buyout ISI was actively interested because their company was taking on water rapidly. I mean, sure, WRS wouldn't mind eliminating competitors, but that's not how it happened.
Back to BSDI. It's a server OS. Sure, as technology marches onward, what was designed for minicomputers (BSD for VAX) becomes more appropriate for embedded. But where was the developer support for using BSDI in an embedded fashion? The company wasn't laying the groundwork for it. They were focusing on the networking appliance market. The code wasn't generally available either. People who wanted to do BSD with embedded were, as far as I know, using NetBSD. Wasabi, for example, was a customization and consulting group for doing embedded and custom network work with the NetBSD base.
So if BSDI wasn't a competitor, why were they bought? Three reasons: First, VxWorks used the BSD network stack, but their codebase wasn't meeting customer needs (TCP use changes in 10 years.. shock), while the BSDI base had been significantly enhanced. Second, BSDI/FreeBSD had some good talent who know their way around such things. Third, Linux was the rising threat in embedded (the storm surge sagged a bit with the dotcom collapse, though it's still around), and developing BSD expertise was seen as a counter to this. BSD isn't GPL, so some more real concerns in the embedded space go away, and well, there weren't any great embedded Linux companies to buy at the time. Besides, I think the nerds over there were kind of BSD-biased, being old crusty types.
Well, I'd say the BSD camp was never too hostile to commercialization of BSD code in the manner employed by BSDI. If you hate proprieterization of free code, you'll probably gravitate to some other project.
No, the reason that Free/Net/OpenBSD people tended to dislike BSDI was because of the vastly unimpressive management of the sourcebase that they got from 4.4BSD. Improvements appeared in only a few key areas (such as the threaded network stack), with the rest vast majority of the system left fairly bereft in a way that would make a default solaris install feel like a breath of fresh air.
Again, fairness: pSOS was developed by WindRiver's traditional competitor Integrated Systems. As ISI spiraled down the toilet of mismanagement and inferior product, WRS bought them, and picked up their product lines for a while. You can bet they discontinued it as rapidly as was at all reasonable for their new customer base.
The transitional APIs predated all this of course, and were marketing tools for stealing customers from their competitor.
It was funny, in the days I was at WRS, (1997ish?) we used to make fun of the things pSOS used to try to sell as features. Example: they claimed faster interrupt times because they required that ISRs be written in assembly. I mean you could write ISRs for VxWorks in asm if you wanted.. but strangely no one ever seemed to want this. As it was, we had a hard enough time talking customers into avoiding excessive templates in C++ (gcc was not very good at this at the time).
In all fairness, they got into the acquire-and-kill business more or less by accident.
They had the core products (VxWorks, Tornado, etc) which were making significant bank, and their stock evealuation was doing great, but they saw themselves as beseiged by various competitors (biggest looming was Microsoft and WinCE). So they took the capital and invested it where their corporate culture said all the value was: Tools.
So they bought all the related tools companies they could get their hands on, thinking this is the way to become the biggest value in the embedded/realtime world.
It's half-right of course. You can't just acuire them, you have to make sure they stay good (hopefully the best). Their eyes turned out to be bigger than their wallets as the market growth slowed significantly for the crash. Integration of dispirate corporate parts took its toll, and many of the best/brightest departed for more pleasant pastures. To control costs they've done round after round of layoffs, ensuring that many of the acquisitions got axed.
And so the American corporate story goes.
To be fair, many axed products really weren't very good, and were just redundant ones from various tools vendor companies.
Some were though. And they've always overcharged for the stuff and acted arrrogant about it. No shock that everyone wants to use linux who can get away with it, as they want to be in charge of their product, not ransomed to an arrogant stoodge.
The problem is when games provide uneven challenge or the wrong kinds of challenge for the player. I enjoy a good exploration, acquire information, put it all together kind of challenge. However, games sometimes provide an obstacle that you have to beat or not progress. If I can't beat it in three tries, I'm not having fun, so I FAQ, or cheat, and get on the with the game.
There are many better ways to design games, including Jak & Daxter's auto-adjusting difficulty, or better information about why you don't succeed when you fail. Other games incorporate RPG-like levelling up, where you can simply work harder to make the game easier if you want to.
Still other games simply provide a more reasonable learning curve, where you learn the play the game better at a reasonable pace, and acquire specific skills by dint of specific levels requiring them, like Warcraft 2 and Starcraft.
Some games just have arbitrarily hard parts which induce massive frustration. See the game ending to Parasite Eve.
For example, if someone manages (as a lucky break) to snarf your password running across the internet logging into a financial site, they could simply have access to private data indefinitely until you change the password. At this point the password would have to be re-acquired for monitoring to continue, which is overall unlikely.
Depending upon the situation, password change can greatly shrink the window of exposure.
As for the continued brute forcing, sometimes there is a lantency between the changing of the access requirements and the access to that change by the crack-attempter.
It seems to me that a number of these inventions probably could be fairly ascribed to several people who contributed small advances which made the idea work.
However, the incontrovertable fact is that toilet paper was invented by the chinese.
The primary difference between Python and C++ is quite simple. C++ is a low-productivity language. By comparison, Python is a very high-productivity language.
By this I mean that per line, or per time, you're getting far more done in Python. Your programs are accomplished much more quickly, and you can move on to the next job.
Like many high-producivity languages, Python is a nicer choice than a languages like C++ except for where it's inappropriate to be used at all. Some examples include: an unusually high speed requirement, a machine-implementation oriented program, a requirement that the language meet some logistical job-world issue like available programmers or ISO spec or some such, a program that requires rigid typing in order to get close to reliability.
The only common case there is the job-world issues.
Note that it's quite possible to build a program in both C++ and Python using object hierarchies that span both languages.
If nothing else, Python is excellent for prototyping C/C++ applications. Find the design errors rapidly, then implement without timewasting. I swear this is faster than writing in C/C++ the first time.
Sure, fine. I meant solved in the sense that the computers are unbeatable, not in the sense that it's fully understood.
Put scare quotes around it for the intended meaning, as you did.
I do think, however, that othello is a lousy game with ludicrous reversals of fate that happen way out the very tippy tip of the increasingly nonbranching gametree, such that endgame solutions are almost more important than any sense of overall strategy. As such, I'm willing to let the computers have it.
As the anonymous coward says, Quake has already been made available to blind players with surprising success. I know about this because I read a website called slashdot. You should try it sometime.
Don't you realize that refresh is balanced directly against persistance to create a stable image? Depending upon the monitor's persistance, a lower scanrate will be as good or better on the eyes than your very high ones. High persistance of course makes rapid motion stuff suffer, so it's not so common, but I've definitely used systems at 60hz without any sort of problem and others (more recently) at 80hz with unpleasantness.
Never ran into the absentia player syndrome in KDL. Probably depends a lot on somebody just not bothering to finish their own turn (Like in Monopoly: There's no reason your turn should last longer than 1 minute. It's roll & move, buy or not, trade or not.)
Did you actually read the rules? In Kill Doctor Lucky, between each turn, the Doctor moves. If the doctor enters a room containing a player, that turn goes to that player. (If multiple players are present the one is selected around the table in clockwise order.) Thusly, turn order is not fixed, and can jump around quite often. If you get caught in an unnumbered room, it's quite likely indeed that you may miss many turns, and possibly never even get another turn in the entire game.
Actually Othello is very much a solved problem. Logistello beat the Othello world champion 5-0 in 199something, so your pocket PC can play better Othello than any human hands down.
Lucky for you, most othello implementations are total crap.:-)
As I said the first time around, they usually are fun for a few plays, but not a lot more, so it largely depends upon how many times through a given game you travel.
That said, Bitin' Off Hedz is pretty lousy. It scales badly, being dull with few and taking far too long with a big group. Few decisions, simple interaction, and plodding pacing add up to a dud. Don't take my word for it though, Plenty of other people think it's terrible too. Scroll down to see the schocking large number of 1 votes, which are normally unheard of on that site.
I find Girl Genius dissatisfying because there's nothing really to be clever about. It's just trying to think further down the tree than your opponents so as to set things up for yourself, but the mechanics aren't very interesting. Lots of brain burn but not much entertainment. Some people like it fine though, so if those don't sound like flaws to you, enjoy!
Kill Dr. Lucky has two major problems. One: it seems like a very casual game, but if you don't take it seriously, it's quite possible to go for exceedingly long periods, perhaps large sections of the entire game, without being entitled to even take a turn. There are stories of people leaving the room and cooking dinner for the rest all the while never having a single turn, and they aren't terribly hard to believe. The 'get a turn when the Doctor enters your room' is essential to making the game interesting, but can lead to a very unpleasant experience for new or casual gamers.
The other problem with Kill Dr. Lucky is that with the provided original rules, there isn't sufficient ability or incentive to attempt to kill the doctor early in the game as opposed to acquiring more cards, and the game frequently has to wait until the deck has been exhausted before the doctor takes the big sleep. This makes the early part of the game lack tension, and the entire game take too long. Various suggested 'fixes' included in the director's cut edition of the game such as "spite tokens" go a fair way to addressing this, but it's clear the game was flawed out of the gate when the revised edition comes with five or more concrete suggestions to 'fix' the game in the words of the author.
That said, I own and love Kill Dr. Lucky. I play it with new gamers somewhat frequently, but with some slight modifications and with a great deal of advance warning about the possibility of turn loss, and that jockeying for turn theft should be of paramount importance. The game works, it's fun, it's one of the good ones.
Some real runts include: Before I Kill you Mr. Bond, Landyland (perhaps unfair to criticize due to the 25 cent cost), swag, and Parts Unknown.
Slashdot Mirror
I think they're both quite likely, and having one pseudo-unavailable due to the other is not good. Further, "where to buy" is a questions trivially solvable via many means including 411, the phone book, asking a friend, etc. The "detailed information on adjustment" is information that you may not e able to acquire anywhere else.
In Linux, scroll lock functions as a CTRL-S/CTRL-Q XOn/Xoff toggle, which is quite handy.
Pause/Break I've used in various games, strangely enough, who use it as a pause key.
In some environments two weeks may be a long time, but the last time I had to use 2k professionally, I lost around 100 dollars in revenue for the time a reboot took. I put off rebooting for the longest possible time while there for this reason, which generally was only about two weeks before swapping became unworkable.
I guess the right solution would have been to reboot the box on saturday or so when no one was there, but I'm not sure that I had the rights to do such a thing.
I wasn't criticizing the specific, but the general. It happens a lot and mailing lists are focused, but externally read. Making things clear as to WHY they don't work and WHY you shouldn't do them is more effective than simply spouting that it is so.
Basically, lack of clarity reaps more trouble later.
/dev/random is not pseudorandom.
/dev/random is fed by a good source of raw stochastic randomness along with other nondeterministic system events into a pool of entropy which is stirred etc. etc.
/dev/random BLOCKS until it can generate enough entropy to be above an acceptable threshhold. Practically speaking, the user can bang away on the (local) keyboard if necessary to generate such randomness.
/dev/random. You don't create a whole device to just recreate rand().
Ideally
If you don't have a good source of raw stochastic randomness (like thermal noise in the intel 8xx chipset or freewheeling oscillators in the new via CPU), then
This is, of course, the whole POINT of
------
But yes, good crypto is HARD to write and HARD to identify flaws in. This obvious fact seems to sometimes escape cryptographers when they review inexpertly created crypto software, who lament endlessly that people get it wrong, and sometimes get sufficiently exasperated to even identify the flaws in comprehensible terms. "This code listing should be self explanatory" being a key sin here.
It's good that someone keeps after 'hobbyist crypto' authors to point out that their stuff is dangerous though. Is there a good communications outreach channel from the crypto community to the general programming community about the dangers of inexpert practice? I'd imagine a website dissecting a few projects in detail could drive home the message: If you don't really know, you're going to do it wrong.
Wow, it's impressive how you turn what could be a rather noble gesture into something small minded and petty.
Computer Industry legend says that the IBM PC design team wanted to use the 68000 but that there was a pre-existing industry deal struck with Intel that allowed them to use the 8080 for super-cheap.
I believe it, but haven't bothered to verify.
You can attach your old amiga motherboard to supply this level of compatability if desired, while not sacrificing the PPC speed of running OS4.
Reduncancy costs.
It costs in equipment, it costs in time, it costs in verifying the reliability of all the parts, and it costs in verifying the reliability of the switchover-on-fail procedure.
Unless you have the organization to keep up all the necessary maintenance on a redundant system, it can become _less_ reliable than a non-redunant one.
Thus, you should not deploy it in all situations. Depending upon the level of investment in the service, a single server can be the more reliable, as well as cheaper, solution.
Right, because of all the embedded development sales opportunities that were going towards BSDI??
Let's review. Was BSDI a highly successful embedded operating system? Was BSDI known for being used in realtime and/or small-scaled operating environments across tens of architectures?
Answers: No, no, and no.
Aside: pSOS was bought for tools and customer acquisition. It was a buyout ISI was actively interested because their company was taking on water rapidly. I mean, sure, WRS wouldn't mind eliminating competitors, but that's not how it happened.
Back to BSDI. It's a server OS. Sure, as technology marches onward, what was designed for minicomputers (BSD for VAX) becomes more appropriate for embedded. But where was the developer support for using BSDI in an embedded fashion? The company wasn't laying the groundwork for it. They were focusing on the networking appliance market. The code wasn't generally available either. People who wanted to do BSD with embedded were, as far as I know, using NetBSD. Wasabi, for example, was a customization and consulting group for doing embedded and custom network work with the NetBSD base.
So if BSDI wasn't a competitor, why were they bought? Three reasons: First, VxWorks used the BSD network stack, but their codebase wasn't meeting customer needs (TCP use changes in 10 years.. shock), while the BSDI base had been significantly enhanced. Second, BSDI/FreeBSD had some good talent who know their way around such things. Third, Linux was the rising threat in embedded (the storm surge sagged a bit with the dotcom collapse, though it's still around), and developing BSD expertise was seen as a counter to this. BSD isn't GPL, so some more real concerns in the embedded space go away, and well, there weren't any great embedded Linux companies to buy at the time. Besides, I think the nerds over there were kind of BSD-biased, being old crusty types.
Well, I'd say the BSD camp was never too hostile to commercialization of BSD code in the manner employed by BSDI. If you hate proprieterization of free code, you'll probably gravitate to some other project.
No, the reason that Free/Net/OpenBSD people tended to dislike BSDI was because of the vastly unimpressive management of the sourcebase that they got from 4.4BSD. Improvements appeared in only a few key areas (such as the threaded network stack), with the rest vast majority of the system left fairly bereft in a way that would make a default solaris install feel like a breath of fresh air.
Again, fairness: pSOS was developed by WindRiver's traditional competitor Integrated Systems. As ISI spiraled down the toilet of mismanagement and inferior product, WRS bought them, and picked up their product lines for a while. You can bet they discontinued it as rapidly as was at all reasonable for their new customer base.
The transitional APIs predated all this of course, and were marketing tools for stealing customers from their competitor.
It was funny, in the days I was at WRS, (1997ish?) we used to make fun of the things pSOS used to try to sell as features. Example: they claimed faster interrupt times because they required that ISRs be written in assembly. I mean you could write ISRs for VxWorks in asm if you wanted.. but strangely no one ever seemed to want this. As it was, we had a hard enough time talking customers into avoiding excessive templates in C++ (gcc was not very good at this at the time).
In all fairness, they got into the acquire-and-kill business more or less by accident.
They had the core products (VxWorks, Tornado, etc) which were making significant bank, and their stock evealuation was doing great, but they saw themselves as beseiged by various competitors (biggest looming was Microsoft and WinCE). So they took the capital and invested it where their corporate culture said all the value was: Tools.
So they bought all the related tools companies they could get their hands on, thinking this is the way to become the biggest value in the embedded/realtime world.
It's half-right of course. You can't just acuire them, you have to make sure they stay good (hopefully the best). Their eyes turned out to be bigger than their wallets as the market growth slowed significantly for the crash. Integration of dispirate corporate parts took its toll, and many of the best/brightest departed for more pleasant pastures. To control costs they've done round after round of layoffs, ensuring that many of the acquisitions got axed.
And so the American corporate story goes.
To be fair, many axed products really weren't very good, and were just redundant ones from various tools vendor companies.
Some were though. And they've always overcharged for the stuff and acted arrrogant about it. No shock that everyone wants to use linux who can get away with it, as they want to be in charge of their product, not ransomed to an arrogant stoodge.
Does that really make sense to you? Because it sure doesn't to me.
Cranium is a "party game" not a "strategy game" which was what was being dicsussed.
I like it, but it isn't the same kettle of fish.
The problem is when games provide uneven challenge or the wrong kinds of challenge for the player. I enjoy a good exploration, acquire information, put it all together kind of challenge. However, games sometimes provide an obstacle that you have to beat or not progress. If I can't beat it in three tries, I'm not having fun, so I FAQ, or cheat, and get on the with the game.
There are many better ways to design games, including Jak & Daxter's auto-adjusting difficulty, or better information about why you don't succeed when you fail. Other games incorporate RPG-like levelling up, where you can simply work harder to make the game easier if you want to.
Still other games simply provide a more reasonable learning curve, where you learn the play the game better at a reasonable pace, and acquire specific skills by dint of specific levels requiring them, like Warcraft 2 and Starcraft.
Some games just have arbitrarily hard parts which induce massive frustration. See the game ending to Parasite Eve.
There are other issues.
For example, if someone manages (as a lucky break) to snarf your password running across the internet logging into a financial site, they could simply have access to private data indefinitely until you change the password. At this point the password would have to be re-acquired for monitoring to continue, which is overall unlikely.
Depending upon the situation, password change can greatly shrink the window of exposure.
As for the continued brute forcing, sometimes there is a lantency between the changing of the access requirements and the access to that change by the crack-attempter.
It seems to me that a number of these inventions probably could be fairly ascribed to several people who contributed small advances which made the idea work.
However, the incontrovertable fact is that toilet paper was invented by the chinese.
The primary difference between Python and C++ is quite simple. C++ is a low-productivity language. By comparison, Python is a very high-productivity language.
By this I mean that per line, or per time, you're getting far more done in Python. Your programs are accomplished much more quickly, and you can move on to the next job.
Like many high-producivity languages, Python is a nicer choice than a languages like C++ except for where it's inappropriate to be used at all. Some examples include: an unusually high speed requirement, a machine-implementation oriented program, a requirement that the language meet some logistical job-world issue like available programmers or ISO spec or some such, a program that requires rigid typing in order to get close to reliability.
The only common case there is the job-world issues.
Note that it's quite possible to build a program in both C++ and Python using object hierarchies that span both languages.
If nothing else, Python is excellent for prototyping C/C++ applications. Find the design errors rapidly, then implement without timewasting. I swear this is faster than writing in C/C++ the first time.
Sure, fine. I meant solved in the sense that the computers are unbeatable, not in the sense that it's fully understood.
Put scare quotes around it for the intended meaning, as you did.
I do think, however, that othello is a lousy game with ludicrous reversals of fate that happen way out the very tippy tip of the increasingly nonbranching gametree, such that endgame solutions are almost more important than any sense of overall strategy. As such, I'm willing to let the computers have it.
As the anonymous coward says, Quake has already been made available to blind players with surprising success. I know about this because I read a website called slashdot. You should try it sometime.
Don't you realize that refresh is balanced directly against persistance to create a stable image? Depending upon the monitor's persistance, a lower scanrate will be as good or better on the eyes than your very high ones. High persistance of course makes rapid motion stuff suffer, so it's not so common, but I've definitely used systems at 60hz without any sort of problem and others (more recently) at 80hz with unpleasantness.
Did you actually read the rules? In Kill Doctor Lucky, between each turn, the Doctor moves. If the doctor enters a room containing a player, that turn goes to that player. (If multiple players are present the one is selected around the table in clockwise order.) Thusly, turn order is not fixed, and can jump around quite often. If you get caught in an unnumbered room, it's quite likely indeed that you may miss many turns, and possibly never even get another turn in the entire game.
Actually Othello is very much a solved problem. Logistello beat the Othello world champion 5-0 in 199something, so your pocket PC can play better Othello than any human hands down.
:-)
Lucky for you, most othello implementations are total crap.
As I said the first time around, they usually are fun for a few plays, but not a lot more, so it largely depends upon how many times through a given game you travel.
That said, Bitin' Off Hedz is pretty lousy. It scales badly, being dull with few and taking far too long with a big group. Few decisions, simple interaction, and plodding pacing add up to a dud. Don't take my word for it though, Plenty of other people think it's terrible too. Scroll down to see the schocking large number of 1 votes, which are normally unheard of on that site.
I find Girl Genius dissatisfying because there's nothing really to be clever about. It's just trying to think further down the tree than your opponents so as to set things up for yourself, but the mechanics aren't very interesting. Lots of brain burn but not much entertainment. Some people like it fine though, so if those don't sound like flaws to you, enjoy!
Kill Dr. Lucky has two major problems. One: it seems like a very casual game, but if you don't take it seriously, it's quite possible to go for exceedingly long periods, perhaps large sections of the entire game, without being entitled to even take a turn. There are stories of people leaving the room and cooking dinner for the rest all the while never having a single turn, and they aren't terribly hard to believe. The 'get a turn when the Doctor enters your room' is essential to making the game interesting, but can lead to a very unpleasant experience for new or casual gamers.
The other problem with Kill Dr. Lucky is that with the provided original rules, there isn't sufficient ability or incentive to attempt to kill the doctor early in the game as opposed to acquiring more cards, and the game frequently has to wait until the deck has been exhausted before the doctor takes the big sleep. This makes the early part of the game lack tension, and the entire game take too long. Various suggested 'fixes' included in the director's cut edition of the game such as "spite tokens" go a fair way to addressing this, but it's clear the game was flawed out of the gate when the revised edition comes with five or more concrete suggestions to 'fix' the game in the words of the author.
That said, I own and love Kill Dr. Lucky. I play it with new gamers somewhat frequently, but with some slight modifications and with a great deal of advance warning about the possibility of turn loss, and that jockeying for turn theft should be of paramount importance. The game works, it's fun, it's one of the good ones.
Some real runts include: Before I Kill you Mr. Bond, Landyland (perhaps unfair to criticize due to the 25 cent cost), swag, and Parts Unknown.