قبل از مطرح شدن Journald سه پروژه‌ی syslogd، rsyslog و syslog-ng متناسب با بستر و پروتکل syslog وجود داشتند. این سه پروژه سعی در حل مشکلات و ایرادات پروژه های ماقبل خود را داشتند اما در مجموع هر سه یک هدف کلی یعنی مدیریت و کنترل لاگ‌ها را دنبال می‌کردند. همچنین همان طور که گفته شد مکانیزم، استاندارد و پروتکلی این سه پروژه روی آن قرار داشتند؛ syslog بود.
لازم به ذکر است که در حال حاضر همچنان از پروتکل syslog و سرویس‌های تحت این پروتکل مثل syslog-ng به صورت گسترده استفاده می‌شود.
در چند سال اخیر با مطرح شدن Systemd، مکانیزمی جدید برای مدیریت و کنترل لاگ‌ها و رویدادهای سیستم با نام Journald مطرح شده است که تفاوت‌های زیادی با پروژه‌های گذشته دارد.
یکی از تقاوت‌های مهم در بین Journald و syslog زمان و محل استفاده از این دو است. پیشنهاد می‌شود از Journald برای سیستم‌های واحد و از Syslog و سرویس‌های تحت آن مثل syslog-ng برای مدیریت و کنترل لاگ‌های چندین سیستم (به صورت مرکزی) استفاده شود.
یکی دیگر از تفاوت‌های مهم Journald در مقایسه با Syslog این است که ثبت و ذخیره داده‌ها در Syslog به صورت متنی انجام می‌شود در صورتی که در Journald به صورت دودویی است.
نکته: در صورت نصب و راه‌اندازی سرویس‌های مبتنی بر Syslog مثل syslog-ng بر روی توزیع‌هایی که از Systemd استفاده می‌کنند، لاگ‌ها و رویدادها همچنان توسط Journald ثبت، مدیریت و ذخیره می‌شوند. در واقع Journald بخشی غیر قابل حذف از Systemd است.
نکته: با استفاده از سرویس‌هایی مثل syslog-ng می‌توان ورودی‌هایی مثل pipe ، socket و پرونده‌های متنی را داشت. به عنوان مثال می‌توان لاگ‌های وب سرور را با استفاده از سرویس syslog-ng مدیریت کرد در صورتی که Journald این قابلیت را ندارد.