A business can refuse a warrant, but it takes a legal response in court. Their attorneys need to convince a judge the warrant isn’t necessary - that it causes a bigger burden on them than the benefit to the public. Most businesses will just comply because it’s not in their interests to spend time and money on it.
Sometimes a business will challenge a court order if it’s about their own customers, employees, owners, or business dealings. The information requested should be relevant to the investigation, minimal to be helpful, and create as little burden on the business as is practical.
Also, if you’re not the subject of the investigation it’s often a subpoena rather than a warrant. There are major differences between these types of order in the US. A subpoena is an order to produce the evidence. A warrant is an order that allows law enforcement to seize it, using force if needed. As someone who has dealt with law enforcement requests for business data about customers quite a bit in the past, it’s often a simple request first and a subpoena otherwise.
I would have several questions before negotiating seriously, and I could actually be in the market for such a beast.
At what multiple would you be comfortable considering selling? If revenue has dropped 85% from its peak, have you identified the cause of the drop? Has it been steady that past five years? Do you have a record of the time spent on it, or does it just feel minimal? How much of revenue is from ads vs subscriptions? Is it sticky mainly because a user can’t export things and import them to Google Calendar or something?
Is it custom software, heavily customized software, or are you basically selling the calendaring component of something like Citadel or Horde? What languages are in use? Does the buyer get just the site or full ownership of the codebase and the rights to derive new products and services from it? Does it come with the domain and trademarks?
Are you selling outright, or are you reserving some royalty for yourself?
What does the handover look like? Does the buyer just get an email with URLs and login credentials, or do you plan on familiarizing a buyer with the whole thing?
The site is localendar.com (you can reach me through the Contact Form there and I can share more financials). Short version: I started back in '99. There were no good calendaring engines back then so I had to build my own (with wicked performance btw ;)). The site is Java/SQL Server. It's sticky b/c it targeted webmasters who needed an easy-to-update calendar for their own site.
The original goal was to aggregate all these local events into a single searchable index and serve up local ads alongside. I never really got that part to take off, though I did get a very early patent for local search on the web. Since then, calendaring libs have come along which allowed many site-builder tools to offer a built-in solution.
The primary reasons for declines are 0) Not as many people build raw sites anymore; people migrate to things like Wordpress or Wix) 1) Google showing less profitable ads and 2) Webmasters w/ a popular site can remove ads via a subscription (which are drastically underpriced; some are still on a legacy $9.95/year). Everything is exportable (and importable) via iCal if desired. Buyer gets everything, w/ no residual royalties to me. I'd have to have an active role in the handover since it's all bespoke code. The buyer would need some level of Java+T-SQL since I don't want to teach coding from scratch.
I love my users and many rely heavily on the site - it's meant to be very simple to use and I tend to draw an older demographic that doesn't need a lot of fancy bells and whistles. 26+ years is a lot of time and I don't have the passion for it I used to. I had a recent health issue and my wife is concerned that she wouldn't know how to close this out gracefully if the worst ever happened.
In this scenario, is the person in the Oval Office a rapist, child molester, serial fraudster, corruptly manipulating stock markets, steering government money to his children’s own weapons companies, assassinating other world leaders, committing the war crime of declaring no quarter, committing the war crime of threatening to destroy all significant civilian infrastructure in another sovereign nation, committing the war crime of threatening genocide, and threatening the use of nuclear weapons in a preemptive military action?
There are still ISA slots in new systems with fairly modern processors and plenty of RAM, if you don’t mind buying specific models of industrial PCs for way too much money.
Or maybe you need 4 PCI and 9 ISA for some reason. DuroPC’s got you, if you can drop $1800 on a system with the same generation of processor. https://duropc.com/product/r810-4p9i-4
This is what the word "bus" used to mean on a hardware level: a backplane of connections to which multiple peripherals could be attached. These days a bus is a LAN of point-to-point serial connections which, it turns out, is much more viable at the high communication rates demanded of modern hardware.
You don't really need IRQs for most ISA boards. OPL3/Adlib sound cards don't need one, MIDI doesn't, joystick port doesn't. I saw various I/O boards that don't need IRQ. Soundblaster does, but I don't know for what purpose. Maybe someone here can explain?
Coincidentally I'm currently working on a Sound Blaster driver for some DOS homebrew, so here's quick rundown of how an SB is programmed and what its resources do:
Base Address: This is the beginning of the IO port range you use to program the card, commonly it's 0x220, but can be configured with jumpers (or software on later cards). You can add offsets to this address to access different functionality of the card, such as the OPL chip or the Mixer chip.
IRQ: The interrupt number that will be fired when the soundcard finishes playback of an audio chunk. Early cards usually used 7, later models defaulting to 5. More on this below.
DMA Channel: Which channel of the PC's DMA controller will be supplying audio data to the card. Usually 1 for 8-bit cards, with 5 being used for 16-bit cards.
The general process for playback is as follows:
- Program the DMA controller with the address and size of an audio buffer you'll be using to mix your PCM sound into. This buffer will conventionally be used in 2 halves by the interrupt service routine, a front buffer and backbuffer, similar to what you'd have for double buffered video. The DMA channel should also be put in "auto-init" mode so that the DMA transfer will loop back to the start when it finishes, which allows continuous playback.
- Install an interrupt service routine to write data into the "backbuffer" half of the DMA buffer, which switches back and forth each time an IRQ fires.
- Initialize the DSP chip via its IO port, pick a sample rate (usually around 11khz for most DOS games), then issue a continuous playback command. For this part, you tell the soundcard that your playback buffer is half the size it actually is, which causes the IRQ to fire once in the middle of the buffer, and again at the end of the buffer before looping back to the start. These halfway IRQs allow you to fill the unused half of the buffer while the other half is playing, for smooth gapless playback with no clicks or pops.
This is probably more info than you or anyone actually wanted, but it's a fun topic so I couldn't help myself.
388h is indeed the original adlib base port. Most sound cards that feature an OPL chip will also monitor reads/writes to this port for backward compatibility with older software, but the FM chip is also addressable from a base port offset.
Incidentally, the DSP isn't actually at 220h, it's at 22a/22ch. How the ports are mapped exactly depends on which sound blaster model you have. What's actually at 220h on older cards is the old CMS chips, while the OPL2 is at 228/229h. As CMS chips fell out of use and later cards featured dual OPL2 or an OPL3 chip, 220h-223h were repurposed for FM writes also, which means you can access the OPL chip from a grand total of 3 different IO ports.
Interestingly, cards with dual OPL2 chips would often be designed such that writes to 388h would actually go to both FM chips instead of just one, so that you still get proper mono sound, otherwise it would be panned hard left.
Sound Blasters and compatible cards used IRQ lines because back in the bad old days CPUs were slow, bandwidth was tiny, and buffers were minuscule.
To get responsive/real time audio the card needs to signal to the CPU, not the other way around, and at the time IRQs were the way to do that on ISA busses.
I would imagine that ISA cards that didn't need IRQs either required CPU polling or DMA.
I imagined that the game / audio driver would just send data to the card at regular intervals and that's it. I realize now that the card uses it's own clock that can drift when compared to the system timer and this method would have a buffer underrun/overrun problem.
In original ISA none of this is managed, the owner of the PC is expected to manually configure both hardware and software appropriately.
So e.g. [with the PC turned off!] you move a tiny jumper (basically just a piece of conductive metal with a plastic housing) to the "IRQ 8" position and you pick "IRQ 8" in some menu or set it in an environment variable in DOS or whatever.
By the time PCI is starting to appear there is some level of "Plug and Plug ISA" but it's fairly crazy because of course all the old stuff still exists whereas for PCI the bus always had this intelligence baked in so nobody just assumes they can pick.
That's correct. I considered whether I should dig out a manual and decided that I should do the exact opposite and pick a value I know won't exist for ISA.
To avoid collisions, you moved physical jumpers on cards that might conflict, to select among a small range of addresses, I/O ports and/or IRQ numbers.
For example if you had two identical network cards, or SCSI disk controllers, you would need to physically reconfigure one of them away from its defaults.
There were only a small number of configurations available on each type of device, and some weren't configurable at all, so you could still get irreconcilable conflicts.
The Linux kernel of the time was full of hard-coded "probe" addresses and I/O ports, probe sequences to see if there was a device there, and IRQ auto-detection routines that triggered an interrupt to find out which IRQ line was asserted. Some of the probes had to be run in a particular order, so that probes for one type of device wouldn't break another type.
Later came ISAPnP, meaning Plug'n'Play for ISA, which allowed the operating system to use a clever protocol to talk simultaneously over ISA with all devices on the bus that support it, identify and select them individually, query what they required and and configure their addresses, I/O ports and IRQs to avoid overlap, or permit overlap where it was ok for IRQs. After the operating system was done configuring them, they operated as if they were configured physically like the older ISA cards. If necessary this could be implemented cheaply by adding an ISAPnP module to an existing ISA card design.
Eventually ISA was superceded by PCI which had better, well-defined enumeration and configuration methods from the start which all devices had to implement. PCI also allowed MMIO and IO base addresses to be set anywhere (32-bit), not just a small number or single option as ISA cards usually had, so there were no more address conflicts. The operating system still had to find the PCI bus registers itself, but after that, probing was simpler and more reliable than with ISA.
USB also arrived around the same time, and also had well-defined enumeration and configuration methods. Many simpler ISA devices were replaced by equivalent USB devices. Although USB was (and is) complex to implement at a low level, the complexity was handled very well by low-cost, generic USB modules on the device side, so it was easy for device manufacturers to use.
There's a shared address bus. Each device responds to the i/o and/or memory addresses it's configured for. Configuration can be static, jumpers, isapnp.
> I assume it’s a master and slave system, but even then were address collisions automatically resolved?
No. If two devices want to use the same address space, you'll have problems. isapnp might help you out, but it was added in the second decade of ISA, so ... lots of things don't use it.
All cards receive the same signals (address lines, data lines, IRQ lines and everything else). They just ignore all data for addresses (on address lines) that are not theirs.
Each card must have a unique I/O address, sometimes more than one and sometimes an IRQ and DMA too. For example, Soundblaster cards had an OPL3/Adlib/FM synth chip at address 388h (it's fixed, you can't have two in the same system, or maybe you can and they would play the same tune, I don't know...), the main chip (wave playback and recording) at 220h or 240h configurable by a jumper, IRQ 2, 5, 7 or 9 (two jumpers), a MIDI port at 300h or 330h (another jumper), two DMA channels (another 4 jumpers), and an IDE port (2 more jumpers).
When you install the card, you set those jumpers according to the manual and what other cards you have installed and their addresses, so that there are no conflicts. Then you add the "SET BLASTER=A220 I5 D1 H7 T6 P330" to AUTOEXEC.BAT so that the games know where in memory to read/write the data so that it reaches the correct card.
Then, PnP was invented, because changing those jumpers and avoiding conflicts was very hard, as you can imagine.
On a PnP system, you would enter the BIOS setup and reserve the IRQs of any non-PnP cards you may have, so that they are not auto-assigned to PnP cards. I/O addresses are managed automatically.
The ISA PnP initialization process is actually very interesting:
All the ISA PnP cards power up in a disabled state. They all respond only to a specific address reserved for PnP initialization. Each card has a unique serial number written at factory. The BIOS scans for serial numbers, not by brute force (that would take too long), but bit by bit.
Let's say there are 3 cards:
A: 010...
B: 011...
C: 100...
BIOS sends an "init command" to the reserverd initialization address. All cards enter selection process.
BIOS asks for bit 0 of the serial number. Cards A and B pull down the line for bit 0. ISA lines are normally pulled-up by the chipset when receiving data from the cards. The BIOS remembers "0". Card C notices that the line is down, in conflict with it's own bit (has "1") and disables itself until the next init command.
BIOS asks for bit 1. No cards pull down the line, both A and B have "1". BIOS adds a "1" to the serial number (now "01").
BIOS asks for bit 2. Card A pulls down the line. BIOS remembers "010". Card B is in conflict and disables itself.
Continue until the last bit. Only card A remains active. For each bit, it either pulls down the line and the BIOS adds a "0" or no response and BIOS adds a "1". There can't be any more conflicts to disable it, since card A is the only one remaining. When the BIOS reaches the last bit, only one card can remain, no matter how many were initially active.
The BIOS then asks for config requirements, and the only remaining active card answers. BIOS configures it with bus addresses, IRQs, DMAs, etc.
BIOS sends the "init command" again. Card A now has specific addresses configured and will ignore the reserved init address. Only cards B and C enter the selection process.
BIOS asks for bit 0. Card B pulls down the line. Card C is in conflict and disables itself. Card B remains the only one active and will be configured.
Repeat the process and configure remaining card C.
At the end, when no more cards remain. Serial number scan returns "1111111..." - no cards to pull down any lines. It means the scan is finished.
The one we’re trying to avoid the most in my household is sucralose. Genotoxicity and upregulating inflammation and oxidative stress are bad things. Accumulating unchanged in the environment and resisting biodegradation is a bad thing.
https://pmc.ncbi.nlm.nih.gov/articles/PMC12251854/
A lot of the “zero” soft drinks are sweetened differently from the “diet” ones. There’s often a mix of different sweeteners so you don’t get too much of any one aftertaste.
The one we’re trying to avoid the most in my household is sucralose. Genotoxicity and upregulating inflammation and oxidative stress are bad things. Accumulating unchanged in the environment and resisting biodegradation is a bad thing.
reply