On Sun, Apr 4, 2010 at 2:33 PM, Michael Sokolov <msoko...@ivan.harhan.org> wrote: > feature blocking seems to negate that. I mean, how could their > disabled-until-you-pay blocking of "premium features" be effective if a > user can get to the underlying Unix OS, shell, file system, processes,
Probably signed binaries, veriexec with a signature list of allowed executables, proprietary system daemons, hardware drivers, and read-only filesystems. Protections may be in hardware, and you do not have source code. You can in JunOS "start shell user root" as much as you like and get a root shell on various platforms, but some functions are limited. Using a 'key' is slightly less of a network operator nightmare than having 100 featuresets, and thousands of mystery meat images for the same software version. At least you don't need to go buy a new software image, and do a full upgrade procedure to gain feature access. Applying a key seems less risky and less likely that downtime is needed, when you decide that you now need this feature. > etc? Wouldn't such access allow smart users to unblock whatever feature [snip] Perhaps, but that would be tedious and probably waste a lot of user time, which can have higher cost than buying a key. The warranty might be voided, and the installation wouldn't be supported anymore, new bugs can be discovered. Upgrades can be required. Even CPU manufacturers are noted for artificially restricting features in software (such as VT or hyper-threading, even artificially disabling cores). Not all buyers of L3 switches need or want to pay for that, and there is more $$$ to be made from those that do. The manufacturer can either segment their market by not offering OSPFv3 on the device, release a new higher-end hardware model for V3 support at 10x the cost, or offer an add-on license, as an incremental upgrade to a larger number of users (including the installed base). -- -J
