I'm using a SATA connected Hitachi GH15F and cdparanoia. This drive, as far as I can tell, is, or was, an extemely common OEM item.
It works absolutely fine with cdparanoia and, if correct offset is set, gives identical results to EAC in Windows (you need cdparanoia 10.2 or newer; older versions had real deficiencies). I checked this with multiple comparisons where I ripped various CDs, some in poor condition, both with cdparanoia in Debian and with EAC in XP and then md5 hashed the raw pcm output: non-different. I also did rips on different drives on different PCs and achieved bit identical results on those drives which passed cdparanoia -A. Obviously this wasn't a huge dataset and doesn't prove anything but it was good enough for me to stop caring any further.
Here is the output of cdparanoia -A:
CDROM model sensed sensed: HL-DT-ST DVDRAM GH15F EG00
Checking for SCSI emulation...
Drive is ATAPI (using SG_IO host adaptor emulation)
Checking for MMC style command set...
Drive is MMC style
DMA scatter/gather table entries: 167
table entry size: 524288 bytes
maximum theoretical transfer: 37074 sectors
Setting default read size to 27 sectors (63504 bytes).
Verifying CDDA command set...
Expected command set reads OK.
Attempting to set cdrom to full speed...
drive returned OK.
=================== Checking drive cache/timing behavior ===================
Seek/read timing:
[47:10.36]: 55ms seek, 0.36ms/sec read [37.4x]
[40:00.33]: 61ms seek, 0.39ms/sec read [34.6x]
[30:00.33]: 51ms seek, 0.42ms/sec read [31.9x]
[20:00.33]: 51ms seek, 0.48ms/sec read [27.7x]
[10:00.33]: 63ms seek, 0.58ms/sec read [23.1x]
[00:00.33]: 66ms seek, 0.74ms/sec read [18.0x]
Analyzing cache behavior...
Approximate random access cache size: 16 sector(s)
Drive cache tests as contiguous
Drive readahead past read cursor: 234 sector(s)
Cache tail cursor tied to read cursor
Cache tail granularity: 1 sector(s)
Cache read speed: 0.16ms/sector [85x]
Access speed after backseek: 0.71ms/sector [18x]
Backseek flushes the cache as expected
Drive tests OK with Paranoia.
As you can see it isn't going to be quite as fast as your old IDE drive but it isn't exactly slow either.
You can safely ignore fetishists who feel EAC is magically unique and that cdparanoia can't do secure ripping. It can, as long as the drive passes the cdparanoia -A test. If you feel the need to compare your rips with rips made by properly configured EAC or dbpoweramp or similar then you need to set the offset correctly.
Almost all the cdparanoia GUI's ignore the offset and don't allow the user to set it, so their rips will have a different checksum than an offset corrected rip by other tools. This doesn't have any bearing on the quality of the rip, only on the ability to compare it. It hasn't done much for cdparanoia's reputation but if you use it with a fully configurable command line front end such as ripit or abcde, or just by itself, you can get 100% secure rips equally good as those produced by magic tools with proprietary voodoo and vociferous fanboys.
ripit is a perl script front end to cdparanoia, it will:
"do the following without user intervention:
getting the audio CD Album/Artist/Tracks information from MusicBrainz or freeCDDB,
ripping the audio CD Tracks,
encoding to Flac, mp3, Ogg-Vorbis, mpc, m4a or als,
id3 tags encoded songs,
creating an playlist (m3u) file,
optionally generating a toc or inf files for DAO burning with, CD-text
optionally preparing and send a CDDB submission and save it locally,
optionally extracting hidden songs and split ghost songs,
optionally creating md5sum files for all tracks,
running several encoder processes at the same time and same run."
Recent versions will also embed covert art in the tags. Basically, if you trust the CDDB data, you can automate everything and even run it in a loop so all you have to do is swap the CD when the tray pops open and then push it shut again. Get a slot loader and become maximally lazy ;-)
http://www.suwald.com/ripit/news.php
xiph mailing list discussion cdparanoia compared with EAC: http://lists.xiph.org/pipermail/paranoia/2009-June/001574.html